-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider deprecating the GUI settings editor #129594
Comments
Here the patch to add back the previous JSON settings editor: json-settings-editor.patch.zip I've just copied the old version from |
🤣 |
Yeah let me just create 2 new issues about this since, apparently, third time's the charm. |
A feature request for improving the GUI settings editor: #131390. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Now that the 3 issues about removing the split JSON settings editor (🔒
#62964, 🔒#64932, 🔒#125952, 206 👎) are part of the top 25 most downvoted issues of VSCode, you should consider getting rid of the GUI settings editor. It would not only mean less code to maintain and new UX feature investment can be focused on the text editing experience of the text editor, but it would also tackle the perceived myth that the split JSON settings editor is a hindrance or is unfriendly to newer users.Keeping this GUI around for a long time is not free and leads to a trail of tech debt that costs developer time that could be spent improving other areas of VSCode. It also represents many lines of code, and as the complexity and download size of VS Code grows, available opportunities should be taken to reduce it.
By default,
workbench.settings.useSplitJSON
should be changed totrue
in order to assess how many users just use the default settings versus how many actually choose their preferred settings editing experience. This is important because default choice matter.In addition, improvements should be made to the rest of the editors to better support key-value languages in such a way that the current settings editor would be made redundant. Instead of alienating users like removing the settings editor does, these changes would empower everyone not only when editing settings, but also in all scenarios where key-value languages are used, such as i18n files.
The text was updated successfully, but these errors were encountered: