Take another look. What you get now is still a gigantic JSON file... except it opens in a two-pane window, with the default settings (including detailed documentation in comments) on the left, and your local copy on the right. And beside each setting on the left is an icon where, if you press it, it copies the setting into your local copy, with all the correct JSON syntax. And usually there's a dropdown showing the different valid options and it uses folding to divide neatly up into sections. Oh, and the settings instantly apply when you save the file.

To me, this combines the best parts of being a text file --- standard commands, formatting the way you like it, you can search it, version controllable --- with the best parts of a GUI --- prompting as to what options are available, easy selection of alternates, documentation, etc. It's an amazingly good implementation and I wish more applications used it.

(e.g. the comment for editor.lineNumbers now tells me that valid options are 'on', 'off' and 'relative', which counts relative to the line the cursor is on.)

Two things to add:

The settings files now have intellisense in them so you don't have to lookup each option.

You can also have a separate settings.json file for that project and check it into git inside the .vscode folder and make those same settings available to your entire team.

We use that in every project and it is great.

This is preciselly the reason I and many of my collegues love it - no GUI for settings. This means you can use hundreeds of tools to manage your settings and it is in true spirit of unix philosophy to keep everything as a text file.

Much more time is wasted by looking for options in GUI equivalent and reproducibility, sharing, backup and comparing (diff) are way harder or nonexistent. Creating frontend for it is trivial, but honestly, why drop from horse to donkey as they say.

All the apps should have settings like that.

Yeah, like many others I maintain my configuration files in Git, so having to use files to configure is a pro, not a con, at least for me! I haven't been using VS Code but this sole factor might be the reason I will reconsider using it in the future.

Some might say having both manual configuration and automated dialog would be better, but many such interfaces ruin the structures of my intentionally organized setting files. I will take no GUI than misbehaving GUI at any time.

This is one of the things I really like about VC, they just implemented their config editing largely the way they support any language: just a json-file (but with comments) which has full-blown intellisense, and offers you a complete example of the defaults side-to-side with clear examples and explanations.

It also allows you to override certain settings per project/directory, which can then easily be included in git (like files to exclude from the file view for a specific project, path/tool settings, indentation settings, ...)

To your point, Atom allows both. Don't like the UI? Just edit config.cson or whatever directly! You're not locked into it.

I just find that if I have to go through a LOT more steps without a UI.

I would rather have devs invest time in serious functionality then doing stuff like GUI.

Otherwise, this quickly turns to nonsence such as Nano server image builder [1] because Microsoft is still babysitting people who CBB to spend few hours to learn Powershell basics and need a GUI that generate 1 liner script.

Microsoft should definitelly rise beyond click next culture.

[1] https://blogs.technet.microsoft.com/nanoserver/2016/10/15/in...

Discoverability and ease of use ARE serious functionality.

To be fair, the settings editor in VSCode shows all the settings possible in a split window with user settings, with neat categories and auto-completion. It's almost like a GUI setting dialog noways and makes it way easier to see what you have changed.

This: https://i.imgur.com/oPYr6Ch.png isn't discoverable?

The comments tell you in detail how each setting works (as you can see, they are even translated), you can search for a specific setting on the top, and it's categorized as well; defaults on the left, your own on the right.

No, wading through a huge text file is not discoverable.

How would you suggest that many settings be implemented in a GUI? It'd have to break them up into groups, and it appears that's exactly what VS Code is doing.

There are different ways to discover stuff. Powershell itself clearly proves that it can be done on system level without any GUI whatsoever.

We had the "ease of use" in GUI paradigm for decades and it didn't hold. Why don't you give it a chance as a text ?

Why do you want to limit yourself to only one way of doing things?

Just curious, is Atom's UI considerate about modifying the content of a configuration file? I'm tired of programs changing the structure of it willy-nilly without even notifying the user (e.g. a click in the toolbar implicitly loads the configuration file and saves it with a different layout). Is Atom OK with this?

This is a problem with Sublime Text too. Don't bother putting comments in your settings file, or rearranging its contents. One hit of Ctrl-minus, even by accident, and your config file is wiped out and replaced with an auto-generated one, which incidentally contains your updated font size. You're welcome.

Seriously, Ctrl+Shift+P and start typing gets me to what I need 99% of the time, it's glorious.

Combined with the VIM plugin and I rarely need to touch the mouse.

I didn't try vim plugin but in general, no vim plugin is substitute for vim.

If you mostly just want the memorized shortcuts to work, they tend to work OK in VSCode, Atom, IntelliJ and even Emacs - Spacemacs is even a better ViM for some.

As someone who did a fair amount of hacking in vimL, evil-mode is a drastically improved vim. It gets basically everything right, out of the box, and extending it isnt nearly as painful as using vimL or interacting with vim's Python API.

> It gets basically everything right, out of the box

Custom bindings don't work on the default document. That's a pretty big failure right out of the box.

And I still prefer vimL to lisp, it's the php of editor extension languages. It's not great for big plugins but ok great to slap things together quickly.

It doesn't, in my experience, get insert mode shortcuts like C-h right out of the box because it clashes with emacs' help mode functionality.

I don't get that mindset at all. I can see desiring a file/command line interface for settings, but to want no GUI option at all for others is just strange.

The difference back in the years of old between running a Linux Server and running a Windows Server is one was GUI based and one is text based. I prefer text based a thousand times over. GUI is fine for single use but for text files it is a simple softlink and git away from having everything the same everywhere.

I use VS Code in three locations in three different OS and I love how it works the same everywhere because I just have text files.

While I agree that a real settings menu could be an improvement, they have made the settings experience better. They show a searchable annotated list of all the default settings on the left, and when you type a setting key in on the right it will show suggestions for possible values.

Looking at it just now, I also see that they added categories, and little edit buttons when you hover over a setting which allow you to click on what option you want. It's a bit strange to me that they're slowly turning a config file into a settings interface, but I guess it works fine for a Developer-focused product.

Well that's good to know -- in that case I'll give it another shot.

> I'd much rather have a nice UI to deal with settings than have to figure out that, say, in order to show line numbers I have to modify "editor.lineNumbers" and set it to "on" (or is it "true"? or 1? I can't remember... let me go waste more time looking it up...)

Maybe you've taken a look at it a while ago. It's still a big json file (great! everything at hand) but very easy to edit since it provides a lot of assistance: there's icons to set a new option, references for everything, and intellisense/autocompletion for the schema of every option you want to change. It'll even show invalid options with a squiggle (e.g. when some setting becomes deprecated).

IMO it's the best way to have settings in an app, especially when you can install extensions that adds settings of their own or when you want settings to be version-controllable.

well, it's an editor for programming. those tools are usually all about typing text, automatically completing text, and validating text. appling those idea to a json config file shouldn't be allien to a programmer.

I use fancy autocompleting and validating text editor for exactly that reason - remembering if it's "on" or "true" or "yes" is too much overhead.

So yeah, json or (preferably) any other markup for settings is fine so long as it hints me with possible values as I type, tooltips each variable with its meaning and so on.

> so long as it hints me with possible values as I type, tooltips each variable with its meaning and so on.

VSCode does this and more. See sibling comments.

How often do you change these settings, though? I choose VSCode for the performance and great addons.

I share your opinion on the settings and command line. While I like it to loads faster than full fledged Visual Studio, in a year or so of using it on Mac OS I still doesn't use even 1% of its features because they are not _discoverable_ at all. Modifying or doing anything beyond text editing require googling. The same apply for using langages extensions beyond syntax coloring. Even Intellisense does not works as expected out of the box so I don't use it.

> still doesn't use even 1% of its features because they are not _discoverable_ at all.

There are now categories in the settings file, a search bar and auto-completion, which should make discovery easier.

> The same apply for using langages extensions beyond syntax coloring.

Do you mean to say that extensions at https://marketplace.visualstudio.com/VSCode are hard for you to discover or that too much of your required functionality is in extensions?

> Even Intellisense does not works as expected out of the box so I don't use it.

If you have found a bug, it would be great to report it at https://github.com/Microsoft/vscode/issues