The author could try forking and patching VSCode to fix the annoyances manually.
Years ago I had an issue with VSCode: it was missing a small feature that was very important to me, with the GitHub issue stuck in limbo.
I ended up going into the source and implementing the feature myself. It took a few hours after bugfixing, I think the fix was ~100 LOC. Then I used the locally-built version. I recall building took a while, and the source and artifacts took a lot of space, but no other problems.
I also created a PR referencing the issue and it got merged rather quickly. Someone else ended up finishing the work since there were some problems (I think relating to coding conventions, and possible edge cases I didn’t need or handle).
Maybe I was lucky for the feature to not require much edits, and probably for the PR to get taken over and then merged fast. But it seems like the author's issues are also small, and it would be easier and more ergonomic to patch VSCode than to create an entirely new debugger.
I had a near-identical experience. I looked into switching in 2019 and ran into this 2016 bug which was a showstopper for me. Fixed it myself, grand total 4 line diff. https://github.com/microsoft/vscode/issues/10643
This is the way. Anytime I have had issues with an open source project, creating a PR even if it's not great will often have it taken over, improved and merged.
I'm sure someone named some "law" after themselves for this. But it is true that the fastest way to get an answer to a question online is not to ask a question; post the wrong answer.
Just a thought that sometimes people developing C# since the early 2000s don’t come from an open source culture, so fixing bugs in someone else’s programs doesn’t appear in their default list of resolutions.
Had you been using Emacs you would have written the fix on-the-fly, eval it and have it be live without even restarting your editor :)
I check with VSCode regularly because obviously an editor that is used by that many developers is worth keeping tabs on (pun n.i.).
I spend some time with it and then go back to Emacs because I can’t justify the trade-off, giving up the raw power and performance for just being more in sync with my team or something.
I’ll readily admit some of the extensions are very nice, like stuff for Kubernetes and so on, and they work well out of box. On the flip side, the customization story is not so great.
With Emacs, I usually spend a bit of time with a new package learning how it works and customizing it to my liking and then it typically becomes more powerful and integrated in my workflow than the VSCode equivalent. Plus the LoC count of a package is usually far far less than of an VSCode extension and I can audit it much faster.
Years ago I had an issue with VSCode: it was missing a small feature that was very important to me, with the GitHub issue stuck in limbo.
I ended up going into the source and implementing the feature myself. It took a few hours after bugfixing, I think the fix was ~100 LOC. Then I used the locally-built version. I recall building took a while, and the source and artifacts took a lot of space, but no other problems.
I also created a PR referencing the issue and it got merged rather quickly. Someone else ended up finishing the work since there were some problems (I think relating to coding conventions, and possible edge cases I didn’t need or handle).
Maybe I was lucky for the feature to not require much edits, and probably for the PR to get taken over and then merged fast. But it seems like the author's issues are also small, and it would be easier and more ergonomic to patch VSCode than to create an entirely new debugger.