Settings UI is overwhelming for extensions with lots of settings

[eamodio]

Specifically for GitLens, I find the settings ui practically unusable -- mainly because GitLens has LOTS of settings, but also because there is no extension controlled order (alphabetic imo doesn't work well), no extension controlled grouping (other than alphabetic proximity), and more. And since the new settings ui became the default, I've seen an uptick in users running into many issues trying to find settings.

To combat this (and really this was long before there was even a settings ui), GitLens provides its own built-in settings editor which is highly tailored and interactive to help guide users. But users have a very hard time discovering it. And again since the settings ui became the default users think that the vscode settings ui is the same as GitLens' settings editor, even when I explicitly provide the command to be run from the palette.

Given the above, I would really love a way from the vscode settings ui, extension page, etc, to at least advertise (or better yet replace/block the built-in ui) and direct people to GitLens' settings editor. Maybe something like a mini-banner with a link or something to guide a user to a much better experience.

/cc @roblourens

[roblourens]

Sorry that you are having these issues. Gitlens is probably a special case here, I don't really want to introduce a general purpose way to link to a different settings UI for extensions or encourage them to go off and do their own thing, because the vscode settings GUI should be the best thing for 99% of cases.

And we will probably never do everything that gitlens' settings editor does, but help me make a list of the things that are missing from vscode's GUI that are necessary to have a better experience for extension settings.

• Control setting ordering
• A level of grouping below "all settings in the extension" level
• ...?

[eamodio]

@roblourens Thanks. Here are some of my thoughts:

• labels (or at least have the ability to override them)
• ordering
• grouping -- maybe shown as a folder in the ToC but also a visible grouping in the main view
• visible separators and/or group boundaries in the UI to make it easier to see the groupings
• collapsible groups in the main ui
• optional hint text for each setting
• info icon links -- to link out to documentation
• image icon hovers or something -- so an icon that would indicate that the setting has an image that can be hovered/clicked on to show it (ui based settings can often be explained through an image so much more easily than words)
• a simple vs advanced toggle to the whole settings ui to reduce the overload of settings unless you want to see everything
• sticky group headers when scrolling
• keyboard support doesn't work well -- no arrow key scrolling, no page up/down support

[mattacosta]

a simple vs advanced toggle to the whole settings ui to reduce the overload of settings unless you want to see everything

Personally, I'd prefer just having the setting not show up in the UI, but still get intellisense support when editing the JSON file in this case.

[eamodio]

@roblourens What do you think about allowing an extension to opt-out of having their settings show up in the Settings UI and instead show a message with a link (similar to Edit in settings.json), but would be a command provided by the extension. Or at the very least, just allow an extension to have a message + link command to direct elsewhere?

That way I don't have to resort to something so hacky like:

[pfitzseb]

One thing I'd love to see would be displaying groups of settings as collapsible elements. Atom has exactly that feature and it helps a lot for extensions with intricate settings:

[usernamehw]

Having images embedded in Settings GUI (hidden by default) would be be perfect.

[AllanOricil]

You could expose a new type of webview for settings. With this new type, developers can choose to override the standard settings window with their own. It could be called WebviewSettingsProvider. It would be different of a simpler webview because the settings would still be accessible from the vscode settings page.

[goyalyashpal]

One thing I'd love to see would be displaying groups of settings as collapsible elements

hi! the following issue/proposal llikely can help with that

• https://github.com/microsoft/vscode/issues/200686

[mark-wiemer]

Shame to see little has been done here recently. For my part, all I'd like is a way to use camelCase in the name of my settings.

Here's what I have now:

"ahk++.intellisense.enableIntellisense": {
    "type": "boolean",
    "default": true,
    "description": "..."
},

But it shows up to users as "Ahk++ > Intellisense > Enable Intellisense"

There is no way to make my title "AHK++ > IntelliSense > Enable IntelliSense", and it make my settings look a bit unprofessional.

I opened #110163 back in 2020, but it was closed as part of this one. However, I think my request is much smaller and can be handled on its own*. Thanks :)

[manwithafox]

@mark-wiemer You may try this:

"AHK++.Intellisense.Enable Intellisense": {
    "type": "boolean",
    "default": true,
    "description": "..."
},

If the string contains blanks it is handled differently: parts between dots are left as is

[mark-wiemer]

Thanks @manwithafox, that helps some problems, but it seems I still can't write IntelliSense with a capital S in the middle 😔 I've tried a good number of combos now. Not the end of the world though!