Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Emacs itself can run as a client and server. To start the server:

  emacs --daemon
Then use `emacsclient` to connect to it. All `emacsclient` instances whether in terminals or GUI are using the same server and can access the same open files and buffers.

Unfortunately it only works locally. I've tried to forward the emacs server socket over ssh to a remote client and it doesn't work.



In retrospect, the name `emacsclient` was a poor one because in 2026 most folks new to Emacs expect it to act like a REST client, where runtime state is synchronized between the client and server over a network. Emacs' usage of ‘client’ and ‘server’ here refer to the usage of a Unix local domain (i.e. file system) socket for simple control commands from the socket client. This was later extended to support a network socket, but the client still only sends simple control commands.


> Emacs' usage of ‘client’ and ‘server’ here refer to [...] simple control commands

Despite that, it still enables this:

> where runtime state is synchronized between the client and server over a network

On graphical X11 frames:

https://news.ycombinator.com/item?id=48864196

but it also enables having multiple TUI `emacsclient -c -nw` frames over SSH.


Forwarding the socket doesn't work, but if you use X11 then you can use `ssh -X`, and the remote Emacs will open a frame on your local X server.

Do beware though that if you use the non-PGTK GTK build, closing this new frame will crash the remote Emacs.


`ssh -X` has awful performance for some reason. You can see each line render individually when invoking the Info manual on Emacs even while within LAN.

It's better if you enable TCP connections on your X11 server, setup a Wireguard VPN between your Emacs host and your X11 server host, and a firewall to only permit X11 connections over that. Throughput and latency then should be so good the remote Emacs window/frame will be indistinguishable from local ones (at least within LAN, haven't really tried over the internet).

> Do beware though that if you use the non-PGTK GTK build, closing this new frame will crash the remote Emacs.

Guess I've used the good one. Haven't had this problem. What I do have is that if you open a frame in a host that you then put to sleep long enough for the X11 connection to timeout on the Emacs host, then `emacs --daemon` will crash. When I've used it, I've just made sure to save buffers often. systemd would start `emacs --daemon` again on its own.

`emacs --daemon` has no problem using multiple simultaneous X11 connections to different hosts, but it just doesn't handle the connections closing on their own. It also doesn't itself close X11 connections when all frames to an X11 server have been closed. So even if you close all of a machine's Emacs frames prior to putting it to sleep, it still causes `emacs --daemon` to crash.


could you see the reason it didn't work?


It's been a number of years, and all I really remember is coming to the conclusion that "emacsclient only works with a local server." It uses a domain socket for this, but forwarding that from a remote server doesn't seem to be enough.

Simply editing a remote file over an ssh connection is easy enough using TRAMP, but that isn't the same as accessing existing buffers in a remote server.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: