-
Notifications
You must be signed in to change notification settings - Fork 29.5k
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
[Feature Request] Port features from old json settings editor #130457
Comments
The fuzzy search would be a nice to have option also in the normal search that's used everywhere else |
This is a much more constructive approach than some others.✌️ I really empathise that this issue has brought out the worst in some community member's attitudes, and that makes it difficult for the core team to communicate on this issue, and may have brought out understandable stubbornness in the core team. But I also think it highlights just how loved and depended on the full featureset of the settings JSON editing was by many long time and power users of Code. It's really saddening that the stripping down of features is being marketed as a compromise, rather than finding a compromise which works for everyone, like:
Just a couple ideas. Please could your team discuss some alternative strategies @roblourens ? |
I compiled a list of features that can be ported to the text editor here, here and here.
With these features added to the text editor, the split JSON editor would've been made redundant. |
I think it would be nice if the pencil had a "Copy to the cursor position" option so that the new setting would not be pasted at the end of the file. |
Don't know if this feature will be useful, but maybe it is possible to make automatic grouping and sorting of the overriden settings? With the possibility to turn it off, of course. |
May I suggest we refrain from adding a wishlist of new ideas to this request? If we do, there is zero chance it'll get implemented. I think we need to plead our case as follows:
Let's make it easy for them to say "yes". |
Ok, that makes sense. I agree. |
Happy to add my voice to this, I very much miss the old JSON settings editor. I have tried the GUI editor recently and it has improved a lot since the last time I used it but I still don't find it nearly as useful as the old JSON editor. For me, the feature I miss the most is the searching functionality, everything else is not that much of a priority. |
Just opened the settings for the first time in a while, and saw the change. I installed a new extension and wanted to quickly scan the available settings for it. The extension's name starts with
I also need to do "quick scanning" when I am debugging problems with extensions (e.g. autoformatting in JavaScript & HTML files comes to my mind right now, since it's something that often gets messed up). In short: neither of the options after the changes is usable for my most common usecases. I would relly like to see the old JSON editor back. |
I think it's time to close this one. If there's something keeping you from being able to use the settings GUI, please open an issue. |
People who reacted to this change don't want to use the GUI. They want to use the JSON editor. And they want the old editor's features back in some capacity. I don't get how someone can still be confused after it became such a mess. It still tops the -1 leaderboard at 138 👎. The 3 "feedback" issues for removing the JSON editor (🔒 This is a beloved feature and this issue is affecting the weekly life of hundreds of programmers, please don't misread the room like that. Or pretend to, whatever, it still aches. We want our favourite tool to be at its best. I have compiled multiple times a list of the quality of life improvements that this editor brought with it, most comprehensively in #125952 (comment). These improvements can be brought to all key-value-based languages like JSON, Yaml, Properties, XML, Toml and others and this is exactly what this issue is about. And I'm not even saying "please implement this", I know it's probably more pain than it's worth, otherwise someone else would've done it already. All I'm saying is that you're behaving in a way that transforms people's legitimate feedback into something completely irrelevant. And I think this behaviour is
*out-of-scope
Anyway, there's still this issue open, which I think is the most important one: But go ahead and lock this thread with a GitHub workflow. |
Extremely disappointing, and not in good faith. An important feature was removed, because the underlying codebase needed to be reimplemented in a way which was easy to maintain. Despite the outpouring of anger (see all linked issues), we understand the concept of tech debt, so politely asked for the old features to be reimplemented in the new codebase. We used your voting mechanism to signal interest, and it's one of the top voted requests. Closing the issue shows there was never interest in dealing with it. Please at least leave the issue on the backlog; you already have 5k+ other issues, why bury this one? And once it's closed the bot locks it after a few days, so we won't even be able to comment on it any longer. If it's open then at least it's still a candidate, maybe someone else will deal with it when time and resources are available. |
Close just before Christmas, so we away or not paying attention. "In bad faith." |
@denisz1 this House Keeping Iteration occurs annually at this time of year. https://github.com/microsoft/vscode/wiki/Issue-Grooming IMO it is an important part of this project sustaining an impressively regular cadence of 11 releases per year. |
Tagging top vscode contributors @bpasero, @jrieken, @mjbvz, @joaomoreno, @Tyriar, before this is locked forever. You insist we use the upvoting process. We did, and upvoted this to one of the top issues, and in record time. And this is not a feature request - it's a request to reimplement features removed while refactoring old code. And we did not harass you, we’ve been patient for years. If you leave this on the backlog forever it would be upsetting, but that’s all. However, closing the issue, even though it has more upvotes than most of the 5,000+ issues, and has a very long and difficult history - which I'm sure you all know about - is both upsetting and very insulting. Many of us do not use GUIs. We use file-based config which is easier to manage in our environments, and works better with git (and the the original issue has dozens of other use cases). I’m sure all of you are power users so you understand the issue. We followed your rules… please don’t make a mockery of your own processes. In the spirit of the season, please do the right thing and leave this on the backlog, or better yet, engage with us. Thank you. |
The "split JSON settings editor" was removed in 1.59.0. This was apparently done because it was old and hard-to-maintain code which represented significant tech debt to the team.
We've all been there - we understand!
Now that it has been replaced by the new editor - which is based on well-designed code that is easy to maintain - please port features that we sorely miss from the old editor:
The text was updated successfully, but these errors were encountered: