The summary is that the author tried to open a remote file and Emacs froze for several seconds. He dived deep into finding out why that was and how to fix it, pointing out how great Emacs's introspection is that one can find solutions to problems like these.
And then two thirds of the way into his essay, he has this:
> More recently, I’ve been very put off by the performance and stability (or lack thereof) of building large scale software via Tramp. This has been sufficient to have me looking out again. On a whim, I installed VSCode for the first time and tried its “remote development” capabilities and holy smokes are they good. Getting up and running was trivial and the performance was great. Saving files was snappy and LSP worked out of the box. What a different experience from my carefully-put-together, half-working, slow Emacs setup.
And then later:
> Improve Tramp performance to match the experience of using terminal Emacs via SSH, or VSCode’s Remote Development.
I think the thing is that pylance is a python LSP. And it's proprietary. So they embraced python LSP, extends it so that the additions are proprietary. And pylance might become the defacto python LSP. Typical EEE. Python is hugely popular, it's everywhere - so even if one hates it, might end up having to use it.
Also the remote extensions are proprietary [1]. This has been discussed on HN before.
They did not embrace LSP. They invented it. LSP came from MS.
> And pylance might become the defacto python LSP.
Nothing is preventing someone from creating another python LSP that will work with the LSP tools. MS is not unique in this. Jetbrains makes proprietary products that are well embraced by the Python community.
Yeah anyone is free to create, same as anyone is free to create remote extensions for VSCodium. So far nobody seems to have done it. Even if somebody does it, it might not match the quality and features of MS extensions.
MS has a history of EEE. Jetbrains doesn't, and as far as I know they are no bullshit no dark patterns high quality.
https://www.murilopereira.com/how-to-open-a-file-in-emacs/
The summary is that the author tried to open a remote file and Emacs froze for several seconds. He dived deep into finding out why that was and how to fix it, pointing out how great Emacs's introspection is that one can find solutions to problems like these.
And then two thirds of the way into his essay, he has this:
> More recently, I’ve been very put off by the performance and stability (or lack thereof) of building large scale software via Tramp. This has been sufficient to have me looking out again. On a whim, I installed VSCode for the first time and tried its “remote development” capabilities and holy smokes are they good. Getting up and running was trivial and the performance was great. Saving files was snappy and LSP worked out of the box. What a different experience from my carefully-put-together, half-working, slow Emacs setup.
And then later:
> Improve Tramp performance to match the experience of using terminal Emacs via SSH, or VSCode’s Remote Development.