Remember user preference of showing keybinds.json and settings.json

[isidorn]

1. Preferences > settings
2. More > open settings.json
3. Close that file now, preferences > settings
4. Notice that the settings UX is open. I would expect that my clear choice in step 2 signals that me as a user expect settings.json

The same can be said for keybindings.json
I think we should really respect the user preference here because we have been shiping with the .json files for quite some time and maybe some users actually got used to it. So we should give them an easy way to show that one by default by remembering their choice.
The settings.json has a button to go back to UX, so I do not see any downside of this approach

fyi @sandy081

[roblourens]

I would rather have a setting to change the default. I think typically someone has one preferred editor and they might want to open the other one for a tweak, but that doesn't necessarily mean they want to make that other editor the default.

[roblourens]

Maybe there should be 3 commands - open the new editor, open the json editor, open whatever the configured editor is. The UI menus would use the third command, and the keybinding would use the third one by default. But you can find all in the context menu or configure new keybindings if you want.

[isidorn]

Settings might work but I do not understand what is the downside of remembering what was last opened - we do things like that across the workbench.
If somebody wants to tweak something in settings.json he has to go back to the settings ux. Same way as someone who opens the output channel just to read some output has to go back to his default terminal panel.
Also what is the use case of tweaking, should the UX be able to do everything that the json file can. Imho this signals a user preference

[roblourens]

Settings might work but I do not understand what is the downside of remembering what was last opened - we do things like that across the workbench

I don't think it's the same sort of use. The two editors are not like tabs on a panel or viewlets in a sidebar. They are editors where someone will probably use one type 95% of the time and maybe use the other some other times.

Also what is the use case of tweaking, should the UX be able to do everything that the json file can.

The UX won't be able to do everything, there will always be advanced scenarios that require the json editor. But many users will be able to do everything they need to in the UI.

[isidorn]

Got it. I still feel like my suggestion is the right way to go here - but that is just personal preference.
Let's try to get more opinions @microsoft/vscode

[miguelsolorio]

I'd rather explicitly set my default settings experience rather than let the editor "guess" which one I want. There are scenarios where you prefer the GUI but still want to editor the JSON for advanced customization or copy/paste settings. Otherwise the experience can become unpredictable/confusing when you get the opposite of that you intended.

[octref]

shiping with the .json files for quite some time and maybe some users actually got used to it

That's me.

The problem for me is now that switching to/from json editor is hidden behind a menu, so it's more effort to switch. A setting like @roblourens suggested, with the three options:

• Always JSON
• Always GUI
• (Default) "Last used"

would work for me.

[Tyriar]

Settings might work but I do not understand what is the downside of remembering what was last opened - we do things like that across the workbench.

I think if it's easy to switch between the two and the toggle was in a consistent position it makes sense to be sticky, but that's not the case right now.

It's pretty annoying for me currently as I'm trying to dogfood but I've found I normally open settings to copy keys and values to help people. I'm definitely not the typical case though and am switching back to "workbench.settings.openDefaultSettings": false and { "key": "cmd+,", "command": "workbench.action.openSettings" } after I've tested it some more.

For configuration I'd like us to land on something like this:

• Setting: workbench.settings.editor:
  • graphical
  • simpleWithDefaults (bad name?)
  • simple (supersedes workbench.settings.openDefaultSettings)
• Commands:
  • workbench.action.openSettings: Respects workbench.settings.editor (cmd/ctrl+,)
  • Also one command in workbench.settings.editor

That way I can configure everything using just settings which are much easier to discover, use and manage than keybindings, while still allowing people the option to bind multiple if they wish.

[ramya-rao-a]

I think if it's easy to switch between the two and the toggle was in a consistent position it makes sense to be sticky, but that's not the case right now.

How about bringing the toggle out and getting rid of the ... (more) menu altogether? (For 1.27 of course not 1.26)

If we add auto-completions to the search box, pressing @ would give you options the first of which can always be @modified for modified settings. With this, the only action from the ...(more) menu thats not reachable via some filter is the open settings.json which can now come out and occupy a permanent position. We could play with the tab order such that the first tab stop from the search box can be the open settings.json link

[kieferrm]

'Modified' is such a common filter that we should not exclusively rely on autocompletion. It's hard to discover.

[kieferrm]

The issue with remembering the last state is that it is not necessarily indicative of what my default should be. For example, I use the keybindings editor and still switch from time to time to the json, for example, for defining keybindings for snippets. When I'm done I close the editor. I don't want it to come up in json again.

Same applies to settings. For example, when I want to customize theme colors, I directly switch to the json file rather than going in the new settings editor through search and the "Configure in json" link. However, although my flow in this instance is the same as Isi's, I did not express my intent to use the json editor by default.

Controlling which one to use by default through settings seems more appropriate.

[roblourens]

@Tyriar what do you mean by "Also one command in workbench.settings.editor" ?

@Tyriar's suggestion is basically what I have in mind right now.

I think the current set of commands e.g. workbench.action.openSettings will follow the setting. Then there will be two more commands (probably don't need the full set of "open workspace/folder settings" commands), one which always opens the json, and one which always open the UI.

I'm not sure what to call these two, either their IDs or display names. Maybe

• workbench.action.openSettings.ui: "Open Settings (UI)"
• workbench.action.openSettings.json: "Open Settings (JSON)"

Will it be too confusing to have those in the command palette? I'm imagining that some people will want a faster way to switch between them besides, open the opposite editor and click the link.

[Tyriar]

@roblourens

what do you mean by "Also one command in workbench.settings.editor" ?

One command for each setting type, so you have a command for the default editor (driven by settings) and separate commands for each editor.

Will it be too confusing to have those in the command palette?

I think exposing all in the command palette is a good idea, that's the best way to discover what VS Code can do (and can keybind).