I mean, quite a few apps aimed at developers do this. Sublime Text for example. I can't imagine many people who aren't comfortable editing a text file would be using a terminal.
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.
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.
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.
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.
> 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.
> 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).