I am a former Emacs user and now a VSCode user. VSCode has great 'remote SSH' capability - running a whole session locally on a codebase that is remote. Everything works seamlessly - find in files, code navigation etc.

That doesnt answer why. I have a table saw that works really well, doesn't mean I use it all day every day.

That's a good point that I didn't make clear, in my head it was implied from context.

Using VSCode in this way makes you much less dependent on good SSH. When using emacs in a terminal over SSH, your whole UI is being rendered over SSH and any latency or packet loss is going to affect UI feedback and rendering.

If you use VSCode Remote-SSH, you UI is rendered locally, so typing and editing work smoothly, and you don't really notice a bit of network latency on a request to "find in files" for instance.

Running your emacs locally and then using Tramp to edit remote files (as suggested elsewhere) gives you some of that benefit but is a much more limited development experience, and (in my experience) flakier.

why do you work remotely at all instead of just doing it all on your pc?

There are a number of situations where you don't want to compile or run code on the same machine that you develop on. Use of containers or VMs can mitigate a lot of them (differing environment or platform), but not all. I have 3 different causes at different times:

Developing a python framework for running system tests on hardware. This can only be run on the machine that is in the lab connected to the hardware. For various reasons related to the network latency of being at home, the easiest way to iterate on that is to checkout and develop on the machine itself.

Developing on Linux, from home. My work laptop is a (small) Windows machine. Normally it doesn't get heavy use - some presentations and email reading when I travel. Now I'm WfH it's my primary machine. By SSHing to my Linux desktop at work (for terminal and for VSCode), I get the development experience of Linux on my Windows machine (there are some other benefits to do with that machine being on the right network and close to the stuff it needs to talk to a lot).

Developing FPGA code. This requires a hugely powerful machine to compile on if you want a reasonable compile speed. The Hardware group have a few specialised machines for this that are shared, so that we can have laptops and get the benefit (also means you can leave a synthesis going overnight/over the weekend easily).

I usually don't even have a PC when remote, it's an Android phone. And when I do, it's a ~2005 x86 netbook - good enough for a thin client, not powerful enough to run the dev stack (which is x64 anyway).

If you're using emacs, you may be able to use Tramp to remotely access the file. It depends on how IDE-ish you've got your emacs set up. As long as you've got reasonable latency I find that much nicer.

(If you already know, well, I'm sure someone else just learned something today.)

Oh absolutely. I like using tramp to edit individual config files remotely. If there is one particular data acquisition computer that is performing incorrectly, I can quickly open up that file to compare, without needing to leave the editor.

The issue I ran into with editing code through tramp is the integration with make. I use `M-x compile` to compile from emacs, with a few modifications to find the appropriate makefile depending on which project I am working on. If I try to compile locally based on remote files, my compile times go through the roof. I suppose I could have opened an ssh session in which to run make, but it was easier to open emacs remotely.

The other advantage is that I could use tmux+emacs to have everything remote, and to connect to that same session from multiple computers. A typical day during an experiment might have me start in an office, later head to an experiment monitoring room, and later head down to the experiment vault to see if an issue is being caused by hardware. With remote editing, I could have the the entire session, including any files that I have already opened, no matter where I am physically located.

If you are in a buffer for a remote file, then M-x compile should run make on the remote machine.

Docs are here: https://www.gnu.org/software/tramp/#index-compile

Ooh, nice. I'll have to take a look at it again. That may be something that I accidentally broke in customizing my environment. I bound `C-c C-c` to look for either a Makefile or a SConstruct in the current directory, walking upwards up the hierarchy until one is found, then to launch either make or scons depending on which one is found. That may have been the source of my remote issues.

Tips if you're writing your own elisp:

- If you're walking the filesystem, make sure you start from the "default-directory" variable.

- If you call other programs, make sure you use "process-file" (for synchronous processes) or "start-file-process" (for async). Using "call-process" or "start-process" unfortunately won't do the right thing, but the two functions I mentioned are mostly drop-in replacements.

Those sound pretty useful, and I will need to try those out. I used (file-name-directory buffer-file-name) as the base for walking the filesystem, which may have caused some issues. I also have a cd in the shell command passed to compile, which probably doesn't play nicely.

Unfortunately, my current job doesn't use Linux as much, and so it has been too long since I've spent time improving my .emacs file, as it is only home projects at this point.

This is actually the root of my italicized "may"; I've seen Tramp do surprising miracles in terms of working remotely with things like this, but I've also seen other things not work because of the various complexities involved. It's at least worth a try, but I've never actually learned elisp to speak of so I have no idea how hard it would be to fix any issues you may find.

I coded PHP like that a long time ago. There was a great editor, maybe called E or something to that tune that would made it seem as if your files were right there locally.