Emacs vs Vim is like comfort food for software-related online discussions.
No shade on Vim, people like it and are productive in it. I see it like using Sublime Text, lots of people can get away with it, but I need more doodads in my editor.
And hey, nobody is like "Notepad++ vs. Visual Studio", which I think kinda matches the mismatch (or maybe "Notepad++ vs Atom" or something)
If I'm actually developing something that's part of a greater whole, then I'm using a fully fledged IDE like PyCharm (but with the VIM emulator plugged in for when I need it, of course ;-D).
Likewise, no shade at Emacs, though. Several of my favorite colleagues use it!
* TRAMP for remote editing. It's more powerful than Vim's netrw remote editing capabilites and can handle root-owned files on remote servers. It's so extensible there's even a package that allows you to edit files inside Docker containers running on remote servers.
* Dired. It's the best text-based file manager out there IMHO, and it integrates very nicely with TRAMP.
* Org mode. It can be used like Jupyter notebook, but is far more powerful. You can write each code block in any language you choose, pass data between them, and make each of them run on different servers. This is very useful for sysadmin tasks especially in professional environments because it allows you to document each step in a reproducible manner as you're executing it. You can then just share the org document for your cowokers to review.
I personally use Vim for coding and Emacs for non-trivial sysadmin tasks.
In 2001, Slashdot held a poll for Best Flame War. [0] The winner, by quite a margin, was Operating System, but the text editor wars (presently being fought at [1]) weren't listed as an option. Personally I'm also rather fond of the tabs-vs-spaces debate.
Until you need to ssh into a server and edit something.
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.
(Incidentally, I don't even use lsp on Emacs, although I may give it a try).
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.
Thanks, today I learned.
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.
If one is concerned enough not to use VSCode because it is MS, then one should also not use LSP.
I don't think this changes the issue: EEE became CEE (Create, Extend, Extinguish).