Yes, but what about remote support? That’s the single most thing I miss from VSCode.
I want to run my editor on the local machine so that it can benefit from graphics support and integrate properly with the local windowing system, but I want all heavy lifting (LSP and the like) done on a remote machine.
Yes, I can use Emacs over SSH (which I do now), but it has limitations. Yes, I could forward X11, but it’s pretty terrible to do so from Windows or macOS.
I tried TRAMP in the past, but it didn’t seem to match VSCode’s power at all in this area. Maybe I configured it wrong though, or maybe it has improved. Any thoughts?
> I tried TRAMP in the past, but it didn’t seem to match VSCode’s power at all in this area.
What was missing. I used TRAMP for years and aside from opening the initial file, it was identical to working locally for me. That said I haven't needed to use it in years, and haven't used the remote support in VSCode.
I remember running into a lot of trouble trying to get the thing to just work. There were some issues in trying to use Windows as the client and some stuff in my zshrc also got in the way. I think I was able to me it run more or less, but I gave up at the time.
I’ve recently been getting into Emacs again and have a pretty good setup already, so I’ll have to try TRAMP again.
You can try using emacsserver remotely. I would recommend using SSH proxying instead of messing with emacs over tcp.
Personally I use emacs on a large dev machine running in a container in a terminal emulator. I can work from my iPad Pro, iPhone, MacBook Pro, Windows Desktop, Linux Desktop, or any guest machine by just adding one public key. Terminal Emulators are still just GUI apps and fit into the GUI ecosystem. Modern emulators also have true color support, GPU based rendering, full unicode support, support for custom fonts that add additional graphics, etc. You can make a terminal editor look like something incredibly modern if you want to. I personally don't find any value in that, for me the basic appearance of a terminal editor is less distracting.
The only time I've seen anyone use "emacs server" or "emacsserver" is to refer to the Emacs Lisp needed to make the command emacsclient (the analog to VS Code's "code" command or TextMate's "mate" command) work.
Correct me if I am wrong, but I believe you are using it to refer to running Emacs remotely without a GUI (i.e., with only a terminal emulator as the UI) even though the person you are replying to specifically stated, "I want to run my editor on the local machine so that it can benefit from graphics support and integrate properly with the local windowing system."
I am writing this to prevent readers of your comment from ending up more confused than they were before they started reading this thread.
You can run an emacs daemon[0] and connect to it from clients both local and remote, including having multiple clients connected to the same daemon and editing the same file with total synchronization built in, you see not only the changes in realntime but the other client's cursors making the changes, for the masochists that enjoy pair programming.
And yes you can run the client using the gui emacs not only terminal emacs.
Your comment is confusing in the same way as the the other guy's is. In fact it is worse.
None of the machinery you describe can be used for anything except specifying files (and line numbers and column numbers) to be visited. An emacs user still needs some way of interacting with the visited file, e.g., a terminal emulator or an X server. This "Emacs server" does not help with that. It's another example of Emacs using unusual terminology!
Have you actually used Emacs or do you just enjoy making pendantic confusing replies?
I tried to use tramp based setup, but ran into many edge cases. Even popular libraries like flycheck doesn't support tramp very well. Eventually I found mosh and that settled the problem. Mosh + iterm2 + terminal emacs[1] combination works very well. Except a few missing features (fringe, variable font size/multiple fonts), nearly everything else works well.
I'm at an organization where our dev machines are in the cloud. Most folks are indeed using VSCode remotely, but I'm happy with emacs.
The combo that works for me (on MacOs locally) is daemon mode and X11 forwarding...but using x2Go instead of vanilla "ssh -X". I end up with XQuartz windows that behave (mostly*) like other MacOS windows and pretty good performance.
If I'm at cafe or somewhere with spotty internet, I'll forgo the X stuff and just use mosh and text only emacs, but I pretty much never do that anymore.
(* mostly, meaning that for some reason tools like divvy and other things that manipulate/resize windows just don't work with X Quartz windows)
> Yes, I can use Emacs over SSH (which I do now), but it has limitations. Yes, I could forward X11, but it’s pretty terrible to do so from Windows or macOS.
Which limitations (that matter)? Maybe I was just too used to vim - everybody is saying use the graphical edition of emacs, but I don't really care. mosh + emacs works great for me.
One thing that helped a lot is making the tmux clipboard transfer to your local computer.
I want to run my editor on the local machine so that it can benefit from graphics support and integrate properly with the local windowing system, but I want all heavy lifting (LSP and the like) done on a remote machine.
Yes, I can use Emacs over SSH (which I do now), but it has limitations. Yes, I could forward X11, but it’s pretty terrible to do so from Windows or macOS.
I tried TRAMP in the past, but it didn’t seem to match VSCode’s power at all in this area. Maybe I configured it wrong though, or maybe it has improved. Any thoughts?