Split JSON settings editor discussion #125952
Comments
roblourens
added
settings-editor
|
While I will miss the fuzzy search filtering, I think this is a good compromise. As for switching scopes, could we maybe just have a toggle button in the editor toolbar to switch from user to workspace settings? |
|
I had the idea of adding a quick access for switching scopes:
For example, the |
|
Not sure I'm following exactly -- typing |
|
Just JSON. Since the GUI has it's own scope switcher. And yeah it could also be launched by an editor action. |
|
Oh no! I've been using the split JSON editor since the beginning. |
|
@jeanp413 What features of the split json editor would you miss that won't be addressed by this? I've also used the split editor since the start and I will definitely miss the filtering, but I don't think I will miss too much else. |
|
@eamodio Definitely the search box to filter the settings and the pencil action to quickly add it to my settings.json instead of typing or copying some setting |
|
The fuzzy search box is priceless. That would be a huge loss of productivity for me. I can copy stuff between panes manually, but it seems to me that finding that setting without fuzzy search would be simply impossible. Now it's so intuitive that I am finding what I want to change by trying 2-3 fuzzy searches, and sometimes hit the bullseye from the first attempt. Please keep it if at all possible. Pretty please. It's like Emacs Ido mode, only much better. Please don't kill it. |
|
I second @kkm000 about the fuzzy search. Using the GUI for fussy search, copy the setting id and then move to the json settings editor seems to overcomplicate things, I see lots of back and forth between panels and frustration in my future if the fuzzy search in the json editor goes away... |
|
There's many places where the split JSON settings could be improved while it's changed and these changes should be reflected in the rest of the editor, without being tied to settings specifically.
These improvements could work in many split-panel scenarios, like editing i18n files in a project. I hope you will consider how awesome the split JSON settings editor is and add its features to the rest of VSCode before removing it. It really is the |
|
The current settings JSON split editor is one of the best features of VSCode, using it from the start, tried the UI editor, never got used to it. Please don't nerf it 🙏. |
|
This settings page was the first feature that really pushed me to give VSCode a try, is so natural to use and easy to share settings If I had to choose only one it would be JSON view 100%, the GUI is cumbersome Please keep it 🙏 |
|
Please leave the json settings editor, the GUI one is annoying to use. |
|
The split JSON editor makes it easy to see exactly what is overridden in the user settings, workspace, and folder at a glance. The features being cited to removed (custom search bar, the scope switcher, the pencil icon for editing settings) streamline the experience. JSON should go back to the default, in my opinion. Telemetry is showing not a lot of people using it because the default was changed to the UI version, that doesn't make it superior. I'd also guess that those who went in and changed it may have also disabled telemetry. I'm not too knowledgeable in the code for these features but what are we talking about in terms of actually maintaining these? It's only tech debt if it is costly (paying "interest" on that debt). As you said, it is custom code just for one editor, can't it exist and function without any need to constantly update it? It is a JSON editor with features on top, which doesn't seem like it would be in flux all the time. If it were intertwined with a bunch of other features, yeah I could see that being a headache and a huge slowdown. I'm not sure I'm buying the download size either, how much larger are we talking? Surely there are much bigger fish to fry when it comes to the app size. |
|
Should this occur, I'll leave VScode!! I will take the dive and make the investment into Neovim and Lua. |
|
If there are only resources to streamline and maintain either the visual menu or the JSON editor, can we have a pol which one to keep? And to save some time, work on removing the visual menu can start right away :) But in all seriousness, to me, some of the JSON view's main benefits are:
The visual editor will never come close to the JSON one in those areas. I do not believe that the minor seeming benefits of the proposed changes outweigh the negative impact those will have on the things that make the JSON editor so fantastic! |
|
I would really miss the ability to comment my settings. I often write explanations for me to remember motives for specific settings. |
+1 to this in addition to adding in some clarifying notes for myself when a setting isn't documented in a way I understand. |
|
I don't like GUI, I would rather remove GUI instead of Json. |
|
I agree that the fuzzy search is useful, and it would be interesting to experiment with a way to search settings using this same search logic using a quick pick control. This seems like a way to tackle it that works within existing VS Code UI conventions, without changing the meaning of the basic editor find widget, or other special logic. It's hard for me to think about how to apply the fuzzy search (or pencil icon) to generic JSON documents since it's implementation is very settings-specific, and I don't think there are other real examples of this split pane defaults/overrides editor pattern. @ryan3E0 It feels like it should be a standalone thing that we never have to touch, but it exists as a component within a larger system that is often in flux. For example, as we've made changes to how opening an editor works in VS Code to support custom editors and notebooks, we recently had to spend a lot of developer hours changing the split JSON editor code to adapt to these changes. And we periodically make cross-cutting changes across the entire codebase or across feature areas which can impact this code. Just in case this point gets lost in the thread, I want to be clear, the thing that is being changed is only the custom split-pane JSON editor. Editing settings in a JSON file will never go away. |
|
@roblourens, I think the quality of the JSON settings editing experience is important. I understand the JSON settings file will not go away (a similar point was discussed the last time this topic was brought previously: #62964) and I do not have a reason to doubt you guys are motivated to do what is best, but I also understand why people may be wary of this change. For comparison, Atom (I just installed it after a really long time to check) has eerily similar Settings and Keybindings GUIs and offers the ability to edit the config file directly (it's yaml in Atom's case). Anyway there is no advanced editing experience, there is no intellisense, I have not found a way to have a side-by-side view with both default settings and my settings (which as other mentioned, I found invaluable to learn about settings and their use, and see at a glance what is the default and what I am using as override). In other words, it is not really usable (one might as well just open the file in Notepad). So, I understand things will change (I'm not sure how much room for discussion is left since this issue is already scheduled for the July release), I really hope the experience will not degrade too much. It would be a real shame. You know what? I would be really curious to see the reaction if you opened a similar issue to remove the Settings GUI, I'd be curioius to see how many people would miss it 😄 |
|
@roblourens, I hear you, and I think that I understand this feeling. I have been a software engineer for most of my working life, and I know that some parts of code look like a burden. I experienced this too many times: a feature is a mess, and it just does not fit the rest of design, but users like it. This happened both in open-source and for-bread-and-butter projects. You see how many people came here to say how they find the feature indispensable. And sometimes it takes more effort to keep something alive, but it's a gratifying effort. Think of this. I have read Raymond Chen's blog for years, and his book too, and can relate to engineers having to jump through hoops on fire to keep the Windows features that even make no sense—like keeping it backward compatible with bugs in enterprise software whose developers had been long out of business. That's necessary for Windows business, but not really a gratifying part of the job. And here you have two dozens of flesh-and-blood Settings is always a tough topic to discuss; a complex highly customizable environment—take Visual Studio, VSCode, Emacs—have thousands of them. For example, key bindings in Visual Studio have a search box, but it first appeared in VS2012, IIRC. How tortuous was it to simply change a key binding back then. VSCode beats the other two in this small sample in its simplicity of finding and changing what you want to customize: Emacs has M-x apropos to search both customize variables and descriptions, not fuzzy; Visual Studio does not have anything even close for settings; neither comes close to a fuzzy search in a single pane which reflects the changes as you type. Then, for VSCode it is much more essential than for Emacs. For the latter, there is Emacs.SO where I can go and find or ask about a particular customization. VSCode is very agile, and in my experience the vast majority of customizing recipes that I'm finding on the internet do not work any more when they are a year or two old, without minor or major tweaks. Options search is perhaps the only way for advanced users to keep up with the changes. It's not a "nice to have" feature. It's an essential feature, really.
The main sticking point for me is the custom search bar. Scope switcher is nice to have, but it's already incomplete in remote development: the UI editor has all three scopes, user, workspace and remote ssh; this switcher omits the remote scope. The pencil icon more often failed on me than not with a cryptic error (in essence, "files have changed, try again", but this did not go away with saving a file, or adding-removing a space and saving it). Search bar is of essence: when I know what to change or to try, I can copy-paste or type, very fast thanks to autocompletion; this is not a big deal. Knowing is. |
|
@roblourens, I didn't know this is the third time (after #62964 and #64932) bringing up this subject, somehow I missed those previous discussions and surely many other people missed them and will miss this one too. |
|
Aight, I'd like to point out the irony behind the Since you weren't listening in the first place, then I guess you can lock the issue before the release of the public build so that people surprised by a sudden heavy downgrade of functionality can come here, confused and dismayed, and really feel the warm welcome of a locked thread? That would be on-brand for someone who opened thrice the same issue and got thrice the same feedback but still decided to go with it anyway. Third time's the charm? |
|
The split editor as it is today is useless to me, at this point it would make sense to just get rid of the entire thing and leave the simple JSON file, why bother with the split view now? It's nothing more than two files side by side I will keep watching this though, I bet more and more people will complain once the change makes it to Stable in just a few days |
|
Found my way here from the little note that's now appeared in the split JSON editor's view and this is possibly the most baffling 'discussion' I've ever seen. |
|
In the future @roblourens, I suggest you either find a more suitable word for... well, whatever this was, or, better yet, don't bother with a farce like this at all. As insignificant as the removal of this feature may be in the grand scheme, the way this is handled is nothing less than insulting and has left a very bad aftertaste. Goodwill is not an unlimited resource, you know. |
|
For me, the split JSON editor doesn't make much sense these days. I've been using it from the beginning and it was great (at first). However, my user settings file has grown to 700+ lines of settings (no comments, just settings) and finding anything in that file is a pain. Besides, how often does anyone go into the settings file anyway? You'll do it a few times in the beginning, when you're getting started with VSCode, then you'll just go occasionally, when a new feature is added or (maybe) when you install a new extension. P.S.: The proof of a 700+ lines settings file, in case anyone doubts that. 🙄 Screenshot
|
|
Everyone has his workflow; my settings file is over 1200 lines (I'm pretty sure many people in this thread have large settings files), I do not edit it every single day but fairly often. Often enough to make what we have today (the GUI or the now broken split editor) very inefficient to use |
|
Those wishing to suspend updates on Ubuntu, run this: |
|
The release notes don't even mention the removal of fuzzy search! People who rarely open settings.json but read the release notes won't even know about this change. The purpose of this is to prevent a wave of negativity immediately after the update? Otherwise, I see no point in such silence - this is not an insignificant change. |
I wish I could thumb down this release note, and there's not even a way to do it. |
|
To disable further updates, use the following settings (ironically, you can't even do this in one step via the GUI editor): {
"update.enableWindowsBackgroundUpdates": false,
"update.mode": "manual"
} |
|
As many of the commenters, I came from a tiny little notification in my settings editor to read this abomination of a discussion. I don't know how many people might have missed the notification. And how many will be taken by surprise. I am not sure if it's only me, but I used to avoid anything from Microsoft like it's the plague. VS Code was different, as it was just too good of a product to ignore. VS Code made me reconsider my stance on MS. I know it's a big brand, and mass compatibility counts more than power user friendliness. VS Code struck the balance, as it was easy to get started with for the masses, yet highly efficient/productive for power users. I know this balance is hard, and that is one of the reasons I liked VS Code so much. Mutilating this tool, and doing so despite all the negative, yet constructive feedback, is sticking the finger to the power users and early adopters. And thus, the better image that MS painted themselves over the past few years breaks down into shattered pieces. It doesn't matter now because most users will never read this thread or not even notice the change. But you leave room for others to attract the power users, as you deprecate their beloved features. As soon as they find something better than VS Code, they will move, and they will draw the crowd with them. Congratulations, you paid technical debt by taking on usability debt. Edit: I even came to late, my VS Code updated, probably while I applied @redomar's hotfix. My disappointment is immeasurable. |
|
Here we go, it didn't take long, one day after Stable got updated: #130245 |
If you refuse to receive updates there's no reason to stay. Both Qt creator and Eclipse have outline / symbol list feature and are cross platform and worth a try. |
|
Like many others I have visited this "discussion" from time to time to vote on the comments. I didn't comment myself because what I wanted to say was already said by other users and I didn't want to spam this issue. But now as this has reached stable I feel like I have to voice my opinion as a comment, since it feels like the votes on the comments are being ignored (given that this was implemented despite the overwhelming opposition to this change). For now I will stick to 1.58.2 for a while and see if maybe our voice will be heard when stable users notice the change and (presumably) voice their opinion here. |
|
@roblourens Congrats! It is now the most downvoted issue in the entire vscode repo, well done! |
|
Is this really a VS Code "team decision", or is it just rob that has been hellbent on removing this since the start, to get his way through? I cannot fathom how a much-belowed feature like this can get removed. Technical debt is a bad argument when we talk about a feature used by many. It is way better than the not-so-good, to put it mildly, GUI experience. VS Code is a tool for coders. The JSON editor is much more natural for any coder worth its salt. |
|
Sadly it seems I am way too late to this discussion and the damage is already done. Nonetheless I feel I should weigh in to "pour one out" for a much loved feature. 🍻 |
|
For those who downvoted this issue, please upvote the following reverse issue as well: |
|
I added feature request #130457 to port features from the old to the new editor. Please upvote. We need 20 upvotes in 60 days. Then, according to their own rules, they can't ignore our pain. (Of course it could go onto the backlog forever. 😞) Nonetheless we need to make a formal request. |
24 upvotes in 17 hours; well that was fast. Let's hope that this pace continues, so it becomes obvious just how much these features are missed. |
|
In case this is a permanent change, I proposed some features that mimic the split JSON editor when using the UI editor, please upvote the issue if you feel the mentioned features are useful (Need 20 Upvotes): |
and others
I'd like to start a discussion around simplifying the split JSON settings editor to make it easier for us to maintain.
Keeping "deprecated" features 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 VS Code. It also represents many lines of code, and as the complexity and download size of VS Code grows, we need to take available opportunities to reduce it. I know it still has some fans, but telemetry shows that it is used very little compared to other features.
I want to think about how to keep some of the benefits of the split JSON editor implemented using typical VS Code UX patterns, rather than custom code just for one editor. Reading through past discussion on the settings editor, it's clear that the most valued element of the split editor is the ability to read the default settings and the user's overrides easily on one screen. We can actually do this easily in VS Code by showing the default settings as a simple text editor side by side with the overrides using the same sort of split editor that we use for diffing.
This lets us clean up code related to the custom search bar, the scope switcher, the pencil icon for editing settings, and some other UI decorations. We could even have an action to toggle the default settings split on or off, which would make this feature useful to people who currently just use the basic json editor. I think this plan is a good balance between serving this user workflow and software maintenance cost.
The settings editor GUI remains for fuzzy search and switching scopes quickly.
The text was updated successfully, but these errors were encountered: