> Are you sure? If I launch a remote session window and click open file/folder, it's on the remote (either SSH or docker for my workflows).

I am not sure about dedicated extra windows. I've not seen it being done in an ad-hoc started shell, inside a normal VSCode editor instance, at least. If it is a new windows (new process) it is not really the same, as the new instance is then dedicated to being a remote session one. With Emacs one does not have to start multiple instances to get things done, but does everything out of the same instance.

Whenever I see people closing and opening VSCode instances, I feel like: "Why did you close that?! Can't you just do things in your editor without frequently closing and opening it again?" It feels like an inefficient process. "I can't do it in this instance, I need to close it and open a new one from another working directory.". I can only speak from what I have observed people doing when screensharing. Maybe other people do it differently or more efficiently.

> VS Code runs a server on the remote with any plugins (including LSP servers) installed with it. This is as opposed to Emacs, which AFAIK does not have a server on the remote and instead interacts with the remote directly using SSH (or `docker exec`, etc). Note, you still need to have any LSP servers installed on the remote if you want that capability.

Emacs has had a server program since ages. You can run Emacs as a server, for example on a remote host, or on your local machine and when you start a GUI or non-GUI Emacs, start in client mode, to connect to the Emacs server. Your Emacs client will benefit from whatever you have set up the Emacs server to do. If your Emacs server has LSP stuff set up, you will be able to use it in your Emacs client.

For merely accessing a remote via SSH and accessing files in it, editing them and saving them, Emacs truly does not need any server. It channels anything one does through the SSH connection and "commits" to the remote's filesystem.

I agree though, sometimes tramp can be a hassle. It could be better and better documented as well.

> Emacs has had a server program since ages. You can run Emacs as a server, for example on a remote host, or on your local machine and when you start a GUI or non-GUI Emacs, start in client mode, to connect to the Emacs server.

I know about that, but AFAIK running Emacs server and client on different machines isn't really supported? Like all Emacs client is doing is executing some Elisp on the Emacs server to tell it to spawn a new frame the same way you can from a regular Emacs instance (that is, the frame spawns on the remote, not locally).

Regardless IMO just using TRAMP and just installing an LSP server on the remote is the simpler and lighter weight solution. The big thing is, I don't want to have to set anything up on the remote. An LSP server that can be easily installed by the system package manager with no further configuration is okay, I deal with that. Anything more, nah.

> With Emacs one does not have to start multiple instances to get things done, but does everything out of the same instance.

Yes, this is a tradeoff, and me being more comfortable with that workflow is one of the reasons I use Emacs. In fact, if so desired, you can still launch multiple instances for different things; me being able to fine tune my workflows instead of my tools dictating them is the big draw of Emacs for me.

>>Whenever I see people closing and opening VSCode instances, I feel like: "Why did you close that?! Can't you just do things in your editor without frequently closing and opening it again?" It feels like an inefficient process.

This is one more thing which emacs/vi people don't get. Most people don't care for things like start up time, or restarting their editor/ide a few times. Because time spent writing code far exceeds a few minutes/seconds of this sort of stuff. When you optimise for things like these, at the expense of features like full remote integration you are optimising for things that majority don't care for things that are irrelevant in the context of modern day development.

>>You can run Emacs as a server, for example on a remote host

vscode is all about doing work the user should be doing. Nobody should be spending lots of times, in case of emacs that's often weeks to months of effort configuring and tweaking things that should come and work right out of the box.

> This is one more thing which emacs/vi people don't get. Most people don't care for things like start up time, or restarting their editor/ide a few times. Because time spent writing code far exceeds a few minutes/seconds of this sort of stuff. t care for things that are irrelevant in the context of modern day development.

It is not, that they/we do not get it in general. You are painting with a very broad brush there. Not all Emacs or VI users are the same. Not all of them/us are endlessly optimizing startup time. Often the opposite is true. We do not optimize it, because we start Emacs when the day begins and close it, when the day ends. Because why would we ever close it at other times? No need to.

It is probably more, that many see it as inappropriate functionality, when one has to close the application and re-open it to do something so simple, that comes out of the box with Emacs. We are used to have this functionality without restarting and we wonder how one could accept this kind of shennanigans.

With VIM or its variants I can tolerate it a bit more, as it is more minimalistic than Emacs in its approach. It is often used as a quick command to open a file on a server, safely (model editing) edit the file and exit (no jokes now!). A one-off operation, not a long session of developing. There are people doing long sessions of development in VI variants as well of course. I have done that in the past, with a heavily configured NeoVIM, using some plugins and it worked quite well.

I would guess, that many people see it as an improper way of doing things, when one cannot accomplish a task directly in ones main editor, but needs to close it or open additional instances of it. The question automatically arises, what the problem is and why it cannot be done in the instance you already had opened. Was the previous instance somehow bad? Does an instance have a half-life period or something, so that it needs to be refreshed?

> Because time spent writing code far exceeds a few minutes/seconds of this sort of stuff.

If I configure for myself in my free time the "optimal tool" and then just copy its configuration into my on-the-job tool, it is my time to spend and does not take anything away from the time writing code on the job. In fact, it even increases my productivity, compared to what some people do with VSCode instances being closed and opened and all that. No one else has to worry about how I personally spend my time. Even if I wanted to spend a few hours a day optimizing my own tooling in my free time, I should be allowed to do so.

If others want to work with less optimized tools or do not want to invest time into making their tool work as well, that is their choice. Doesn't make it less painful to watch in screensharing sessions though.

>>You can run Emacs as a server, for example on a remote host

> vscode is all about doing work the user should be doing. Nobody should be spending lots of times, in case of emacs that's often weeks to months of effort configuring and tweaking things that should come and work right out of the box.

Now you are just setting up a gigantic strawman. What kind of configuring around have you done, that took weeks or even months? Who would even be willing to do that, without looking for help from other people, who already have configured something similar? No single thing would take that long to configure. What you may be confused with it incremental improvement. Over the life of an Emacs setup, perhaps over a time-span of 10 years or so, it may well happen, that one spends weeks configuring things. Obviously not necessarily in one long marathon, but over time tweaking things. Half an hour here and there, to make life more pleasant and move beyond lowest common denominator functionality.

I agree, that one should not spend a lot of time configuring things before getting anything done, unless one has the time. However, default Emacs already is quite capable and I could easily work with that.

It would also only take me a minute to install a theme I like and perhaps magit. The return of time investment for magit is enormous, since I already know it, so I would install it right away. Hitting some M-x package-install RET magit RET takes less than a minute and makes every git interaction I am likely to need much faster.

The thing is, that with Emacs one gets things which one does not get in VSCode at all, no matter how long you configure VSCode. I personally expect more from my tooling and that is my choice. Who are you to decide what functionality I am to expect out of the box and what I am to not expect at all?

Honestly speaking the only real use case of vim/emacs style keyboard heavy editors I can see(having been a user for years) over vscode is use of keyboard macros. Which in modern context is rare enough to make a one off sacrifice.

But otherwise the only real use case for vi(m) is I see is server side editing, and its still the best tool out there for such tasks.