I used to, and I probably would if I had to work with remote files more often. But in my experience I found it faster to just build emacs on the remote server and run it as a daemon there, since all the machines I was working on remotely had /home on an NFS mount. TRAMP took just a little too long to load remote directories for my liking.
But in case I am plopped in front of an unknown terminal/have to do something on someone else's machine ... at least I can rely on using the default vim to do basic editing.
Does that mean you have a nice setup for running emacs as a server on a remote machine and connecting via a local client? I've tried this a couple of times but it seems to be prohibitively awkward and I'm stuck with the idiosyncrasies of Tramp or even just saying in a vterm. I'd be very grateful if you (or anyone else) can explain how to do this.
I just run emacs on the remote server (inside tmux), emacs works great on the terminal, in fact, I don't use GUI emacs. code, orgmode, magit are just text.
Yeah, this is how I do it. If it's a reasonably modern remote image you even get color highlighting. And in a way, it lets me segregate, "on this host, I'm working on this project, on this host I'm on this project, all the state/context is there when I re-activate my tmux ready to see what's up.
If I'm writing a lot of code or doing a refactor needing more thought, I'll do it locally, to be sure.
I even started baking emacs into docker images we use for running debugging tools in kubernetes environments. Can quickly edit and run little scripts to do admin and operations and debugging tasks.
You can also use docker-tramp to enter locally running containers and do quick edits without worrying about installing an editor. It can be suprisingly useful.
But in case I am plopped in front of an unknown terminal/have to do something on someone else's machine ... at least I can rely on using the default vim to do basic editing.