9 ms·

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

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.

omni 3y ago
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 https://github.com/microsoft/vscode/issues/10643
sam0x17 3y ago
Sometimes it's easier to start from scratch than figure out how some storied monolith works
- xtracto 3y ago
  This article by Joel Spolsky has some good advice related to that: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... Tldr: avoid rewriting software. Most likely the gigantic monolith got big because because of all the business logic encoded in there.
nailer 3y ago
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.
- doctorwho42 3y ago
  Best time to learn was 10 years ago, the second best time to learn (and add it to their default list) is today!
segmondy 3y ago
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.
- jjeaff 3y ago
  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.
  - p4ul 3y ago
    You are correct! This is Cunningham's Law [1]! And it seems exceedingly plausible after observing behavior on many online forums! [1] https://meta.wikimedia.org/wiki/Cunningham%27s_Law https://meta.wikimedia.org/wiki/Cunningham%27s_Law
lilbaby 3y ago
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.

omni 3y ago

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 https://github.com/microsoft/vscode/issues/10643

sam0x17 3y ago

Sometimes it's easier to start from scratch than figure out how some storied monolith works

xtracto 3y ago
This article by Joel Spolsky has some good advice related to that: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... Tldr: avoid rewriting software. Most likely the gigantic monolith got big because because of all the business logic encoded in there.

nailer 3y ago

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.

doctorwho42 3y ago
Best time to learn was 10 years ago, the second best time to learn (and add it to their default list) is today!

segmondy 3y ago

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.

jjeaff 3y ago
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.
- p4ul 3y ago
  You are correct! This is Cunningham's Law [1]! And it seems exceedingly plausible after observing behavior on many online forums! [1] https://meta.wikimedia.org/wiki/Cunningham%27s_Law https://meta.wikimedia.org/wiki/Cunningham%27s_Law

lilbaby 3y ago

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.