I had to figure out how to do rectangular copy/paste in vscode, and it took just as long as it did to figure it out in emacs.
https://stackoverflow.blog/2017/05/23/stack-overflow-helping...
"Most people don't know how to use vim and emacs" is both incredibly controversial around these parts and totally true.
I would say that the dev client/server setup you're describing and what TRAMP provides are different things overall as well. TRAMP really just provides a way to get a file from a remote, edit it locally, and on save write it back to the remote system. I would not consider it a valid use case for remote dev especially now with how prevalent things like LSP's are and I don't know of a major mode that is designed around a remote LSP I'd just do X forwarding or some other screen share at that point. I would agree that overall it's a gap for emacs that VS Code does better.
Trivia: the original Emacs (written in TECO for PDP-10s running ITS) also had transparent access to remote filesystems using the same syntax (host:path).
It was free though: remote files were accessed over the net via a FUSE-like userspace process.
In the mid 1970s.
https://emacs-lsp.github.io/lsp-mode/page/remote/ suggests that LSP under TRAMP is basically there, though I haven't had occasion to try it.
cd /sshx:host:
ls
any remote command
It is quite impressive how well it works. Most lsp modes are tramp aware, such that completion and tag jumping will also do the right thing.I haven't used VS code yet, simply because of lack of time in relearning another editor. In which particular way do you feel like VS code remote plugin is superior to the alternatives? And is there anything lacking in your VS code experience as of today?
To me, emacs is a great editor with variable quality IDE-like capabilities, highly dependent on workflow.
VScode is sort of the opposite. It's an at best ok editor with a strong suite of IDE capabilities that are mostly consistent.
In emacs I have to either add pretty complicated scripts to my .emacs just to get stuff to play together if it's even possible at all, or stay in the terminal and run it all on the remote (and put up with the lag, and re-mount/upload my configuration when a new instance starts).
For the longest time I used emacs on the remote and pycharm/jetbrains locally (and was a vscode skeptic) - that changed once I saw what the remote dev plugin was capable of (jetbrains doesn't have an equivalent). I still use emacs in the terminal on remotes for quick text editing, but for project work vscode works better specifically because it's easier to resume on disconnect (one-click restore of all state) and easier to configure. I use tmux in the vscode terminal to resume remote shell sessions.
More importantly, it's a lot easier to onboard others to vscode because the IDE as a whole is more discoverable, more user-friendly, and follows platform conventions more closely compared to emacs or vi.
The one big feature that I miss in vscode is tab key behavior/intelligent indentation. Emacs does this way better - tab just does what I mean, instead of inserting a useless literal tab or spaces.
Even python, if I M-x run-python while on a remote file, it runs python on that remote machine.