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