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…
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.