You appear utterly convinced that VSCode will never demonstrate an obscure bug like the one discussed in TFA, or alternatively that if it does you'll be able to jump ship to some other tool. I don't share your confidence, and would prefer to know that such issues can be fixed with or without vendor participation.
That seems an ungenerous and quite broad interpretation of a fairly simple assertion.
Even as much as I love Emacs, I would never fault someone for choosing a more productive tool now even if there’s a non-zero risk of something breaking in the future...because there’s always something that will break on any platform. Time spent being productive now is usually worth that risk.
The counter-point to that is that the world benefits more by someone choosing to actually fix whatever was wrong, rather than just switching platforms (or never choosing it in the first place because they came across the post on HN).
The claim in the comment I was responding to appeared to me to be "hmm, Emacs has a problem, VSCode probably doesn't, I would rather use VSCode". It didn't seem to me to be written with much awareness of what the actual problem in TFA really was, nor with any real knowledge that VSCode actually would be more productive. It seemed to me to be more like "Ewww! Emacs has a bug, someone fixed it with a lot of obscure stuff, no thanks, VSCode here I come".
I certainly respect that for many, VSCode will be a more productive platform when measured by the metrics that matter to them.
> the world benefits more by someone choosing to actually fix whatever was wrong
Maybe.
I imagine at some point someone wrote ffap-guess-file-name-at-point to fix a problem. And the blog author solved a problem by disabling it without knowing what problem it maybe solved.
Problems eventually become complicated enough it’s not a binary fixed/broken, but rather a matter of trade-offs.
Open source and shared solutions are great. But they aren’t a silver bullet either.
There were two points in my comment. One was of feeling like an imposter, in that even as a software engineer I lack both the patience and skill to pull the debugging off the article showcased. It's both admiration and lament at the same time. The second point was that I personally prefer to altogether avoid issues like this if I can by selecting what I feel is the best available tool at the time. I have tried to use Emacs multiple times, and while this exact issue is not one I have encountered (I did say "these types of issues"), I have come across similar issues, especially with having Emacs talk to another computer or VM. Every time I have tried to get into Emacs, I end up hitting some barrier akin to these things, and so I resign myself to using Visual Studio Code, where then I get off to coding rather than trying to bend the environment to what I'd like. And it always seems that with Visual Studio Code it both does what I'd like and works without a million gotchas.
Visual Studio Code is not perfect, and I have had issues with it and expect more issues. However, they don't hit me as early as they seem to with Emacs, and that's an important distinction. The remoting extension is extremely seamless, and I have not seen an Emacs example of matching anything close to it.
It really comes down to personality. If I was a carpenter and had a broken hammer, I wouldn't go off rebuilding the hammer or designing one from scratch. I'd do my best to find someone else who's already built a hammer that works. That doesn't imply I never expect the hammer to never break.
> would prefer to know that such issues can be fixed with or without vendor participation
Visual Studio Code is open source and well-managed. I'd prefer that a solution be merged into the tool for everyone, rather than being buried in someone's .emacs file.
Your explanation involving containers/VMs makes a lot more sense to me than avoiding specific bugs when using Emacs' equivalent to VSCode's remoting extension.
As a purely native developer, I have zero use for such things, but I can certainly appreciate that VSCode may have done a much better (or certainly, shall we say, a less historically indebted) version of this sort of functionality than Emacs.
