[qayxc]

The configuration file opens in whatever app is associated with the format.

If you associated JSON files with VS then that's specific to your personal setup and unrelated to the Terminal app.

You also don't need to learn JSON schema and - I'm sorry to say this - but if editing a well-documented text format is too much of a hurdle to you, then maybe you're simply not the target demographic for the app.

The tons of people who blindly use copy-pasta wouldn't even need to use the Terminal app (a tool explicitly aimed at power users and devs), so that's a non-argument to start with.

[oefrha]

Thanks for labeling me a noob while I have been editing text configs for a decade and a half. Again, passable != good, and there’s hardly any defense for a GUI application putting all common settings in a text configuration, especially when you need to configure colors, fonts, etc.

I’m pretty sure the terminal app was advertised as the next generation console experience for Windows, which means it is going to replace cmd, and will be used by non-power users.

Re binding: that’s just the default when VS is installed. Also, whether it’s Visual Studio is irrelevant, what’s relevant is it definitely isn’t Windows Terminal.

Edit: By replacing cmd I probably meant replacing conhost or something. Not completely sure about Windows separation of shells and terminal emulators but the idea should be clear.

[laumars]

For what it's worth, I agree with you. JSON is meant to be machine readable rather than human writeable and while I don't mind reading through JSON files, I really don't enjoy editing them because it's easy to break (eg including a trailing comma on the last entry in a map or array).

The lack of comments in JSON is an often raised point and it's really useful being able to add comments in a "living" config file.

The other issue I have with many JSON config files is they don't always contain all the options, so you end up having to search around for what the right directive is to add to a particular config file (this is my biggest gripe with hacking VS Code config files). This is less of an issue with other formats because you can often comment out lesser used directives.

I think the reason JSON is popular for config files is because it's easy to implement rather than easy to maintain and I see JSON as a regression from the TOML / INI etc formats that used to be commonplace beforehand.

I also agree with your frustrations with the replies about "people who know how to use a terminal know how to use JSON"; sure they do but that doesn't mean it is appropriate usage of JSON. I could write a config file using golfed Bash and say "but you should know how to read and write Bash" but people would understandably dismiss that saying it's still not user friendly and I don't see your point here any different.

[frosted-flakes]

Note that the JSON config files for Windows Terminal and VSCode do accept double-slash comments.

Annoyingly, they don't allow trailing commas, but I suppose it's easier to strip out comments before parsing than it is to customise the JSON parser.

[s9w]

People who use a terminal know how to edit a json file. That approach has good tradition by now with Sublime etc, see the poster above. And I'm pretty sure VS doesn't auto-associate itself with json files. They handled this in the best way possible imo.

[oefrha]

Last time I’m gonna say this: configuring fonts, colors, etc. is possible with a text file, doesn’t mean it’s any good.

[s9w]

That's up to opinion. I just wanted to join in to voice another opinion since some people in MS have recently been on a "even a single opinion is enough to act" policy (see VS Santa hat debacle), which I'm trying to prevent.

[dragonwriter]

> and there’s hardly any defense for a GUI application putting all common settings in a text configuration, especially when you need to configure colors, fonts, etc.

It's a good place for them to be stored; it's not a great UI, but that is a thing that can be built over any storage and there is a reason it's v0.10 and not v1.0.

> I’m pretty sure the terminal app was advertised as the next generation console experience for Windows, which means it is going to replace cmd

ConHost. Cmd is a command interpreter that runs in a console, not a console itself.

> and will be used by non-power users.

Eventually, sure. It's very much a power-user-focussed preview today, though.

[qayxc]

> I’m pretty sure the terminal app was advertised as the next generation console experience for Windows, which means it is going to replace cmd, and will be used by non-power users.

I'd love to hear a legit day-to-day use case, though. I'm honestly very curious to hear about that since even as a developer, I pretty much never use the command line (outside of WSL, which I don't consider a typical use-case either).

[throwaway17_17]

I work outside of software (or any technology really), so I deal with around 30 people who are the opposite of power users, all using Windows (with one on a Mac laptop). Not a single one of them would even know what a terminal is, and I include powershell and the standard command line in that. The only thing that runs on their machines via Windows cmd are scripts I install so I can use their machines if I have to get something done on it.

[majkinetor]

I bump terminal stuff on random non IT useres and my exprience is the opposite.

[vips7L]

How do you as a developer never use a shell? I'm genuinely curious. How do you compile, install dependencies, etc?

[qayxc]

I didn't say I never use a shell - I even explicitly excluded WSL.

When developing software in Windows, however, there's simply no need.

> How do you compile

I press F6 in my IDE.

> install dependencies

I click "Add nu-get package"

> etc. [I assume version control operations and the like]

Again, I simply use the built-in tools of my IDE of choice which are usually bound to hotkeys.

This is hard to fathom, especially for modern web development, but I don't do web development and the embedded systems I work with don't have a shell while the GUI programs have, well, graphical interfaces :)

[majkinetor]

> When developing software in Windows, however, there's simply no need.

This tells more about your skils then anything else. If there is NO NEED for that in your world, there is defintelly a NEED for you to dive into it - something you don't know you can't use or find a need for it.

[noisem4ker]

Integrated development environments, or IDEs for short.

[majkinetor]

Its double work. You mandatory need CLI for build server anyway, and you generally DONT need IDE for anything

[nicoburns]

I use the shell everyday for git, code search, running my code, SSH. I think on windows it's more common to use an IDE with a GUI for some of these things, but the CLI is generally more powerful.

[qayxc]

I was rather curious about strictly non-power-user use cases. Someone who develops software and uses distributed version control systems isn't exactly the average user.

Especially on Windows.

[majkinetor]

I think you are babysitting users too much.

Terminal is basic IT literacy. Or at least, it should be. And it can't be if you protect people from it like its some kind of baba yaga.