Remote emacs server, local client

Has anyone tried to get this working? Right now I have a cloud instance where I run my code, and a local emacs environment for editing it. I run LSP and stuff locally, and I periodically rsync my changes up to the instance. It kind of sucks. I tried to make TRAMP work before ending up here, but i just could not TRAMP + LSP working. It occurred to me that maybe there would be a way to run an emacs server on the instance and have some kind of a thin client locally. I messed around with forwarding the server socket over ssh, but it turns out that emacsclient will just try and get the server to do stuff on its end. In other words, emacsclient is just an RPC call, not a thin client. X forwarding is way too slow. Anyone got any other ideas? if it wasn't clear - I want emacs running on my server, with a GUI on my laptop. I'm envisioning something like a web app - backend <=> frontend

tramp and eglot works absolutely fine ; no problems. Just make sure that remote path is working. https://www.gnu.org/software/tramp/#Remote-programs

You need to more clearly explain what you want. You don't want things to run locally, but you also complain about them running remotely, so… what do you want? > …it turns out that emacsclient will just try and get the server to do stuff on its end. Right. That's how client-server architecture works.

if it wasn't clear - I want emacs running on my server, with a GUI on my laptop. emacsclient can make the server open buffers/frames on its end, but that's it I'm envisioning something like a web app - backend <=> frontend

I use lsp-mode, not eglot. and it *almost* works! i've spent enough time down that rabbit hole, and i acknowledge that maybe there's a solution in there somewhere. i'm trying to explore alternate paths atm

[Recent, similar thread](https://www.reddit.com/r/emacs/comments/tpml3k/suggestions_on_remote_work_with_lsp_how_do_you_do/?utm_source=share&utm_medium=web2x&context=3). Emacs really reminds me of my erstwhile preoccupation with aftermarket modding. There's an unexciting, corporate-imposed environment (in your case, the cloud instance) where the rubber hits the road, and where you're expected to make do with `emacs -nw real_work.c`. Mind you this isn't an unreasonable expectation. In a former, more lucrative life, I made a ton of progress and received many promotions keeping my eyes on the prize without the "benefit" of LSP and similar niceties. But to the typical denizen of r/emacs, for whom, like the twenty-something ricer, simply getting from point A to B in a Toyota Corolla is unbearably straightforward. No, the work is worse than meaningless unless we can apply our personal flair. Emacs is the equivalent of the 1995 euro bmw m3 (OBD1). We won't get there as fast as the current fly-by-wire *poseur* m3, but we'll get there in style.

thanks for the link! actually, most people at my company use VS Code with a remote development plugin which works with its own language server client implementation. but i'm stubborn and i like emacs soooo

> I'm envisioning something like a web app - backend <=> frontend Yes, that's how it works. Virtually *everything* that's happening in Emacs is happening in the server process. Emacs is the server. The clients are pretty much just I/O -- you type things into it, and it renders what the server tells it to render. I think you're confusing things by mentioning this web analogy. Your question is just how to make a local emacsclient talk to a remote Emacs server process. I think people have managed this using TCP rather than sockets. My recollection was that even then having the two processes on different hosts isn't really supported, and that it was considered something of a hack to have it working (if you can do so at all); but some older docs certainly suggest it's a recognised use-case: > Even if local sockets are available, you can tell Emacs to use TCP > by setting the variable `server-use-tcp` to `t`. One advantage of > TCP is that the server can accept connections from remote machines. > For this to work, you must (i) set the variable `server-host` to the > hostname or IP address of the machine on which the Emacs server > runs, and (ii) provide `emacsclient` with the server file. (One > convenient way to do the latter is to put the server file on a > networked file system such as NFS.)

see.... i don't think you're quite right. as far as there is such a split emacs is both the server and the client. "server" mode seems to be more like starting an RPC server ("openFile", "createNewFrame", etc) i got a local emacsclient talking to a remote emacs server instance, but it could only *have the server open the files there*. it couldnt open a "frontend" locally to talk to the server.

The `emacsclient` process is "the frontend". The server is the `emacs` process, where everything happens. Perhaps you have a different definition of "frontend", because I don't understand what it is that you expect to be able to do with one, other than ask the "backend" (server) to do things. Can you provide a *very specific* example of a thing you think you should be able to do, but cannot. Use explicit (if made-up) hostnames and filenames and whatever at each step so that it's unambiguous, because we're not currently on the same page. The more detail, the better.

Basically you want X, where the display is local and all the smarts on the remote machine, but perhaps a smarter more specific client that performs better over network connections. I could see that being cool, but that isn’t something that I have ever seen done.

> X forwarding is way too slow. In these situations I usually `ssh` into the remote host and run `emacsclient -nw` to use a terminal client frame. The terminal-oriented network usage is dramatically more efficient than X forwarding; so unless your connection has really bad latency or is hanging frequently, this works very nicely. Obviously you lose the GUI-ness, but if it's a choice between good performance in a terminal or bad performance in a GUI, I'll take the former every time. If you have significant network issues, then Tramp would be a better option.

ec2 instance: running emacs server, named socket laptop: * ssh is forwarding server socket to local in background * $ emacsclient -s /tmp/mysocket /home/me/some-file-on-server opens file in the running terminal emacs session * $ emacsclient -s /tmp/mysocket /home/me/some-file-on-server -c error: cannot connect to /dev/stty10 (or some such) what i want: i want a local emacs gui frame to appear that's connected to the running emacs server. imagine a web app again. backend running on a server, frontend running in my browser. that's where i'm trying to get to

yeah pretty much.

[TCP-Emacs-server](https://www.gnu.org/software/emacs/manual/html_node/emacs/TCP-Emacs-server.html) maybe what you want.

Per my earlier comment, I believe you *need* to use the tcp support to do that. AFAIK usual socket-based approach won't (can't) work. I've never done this myself so I can't comment further, but my understanding is that the tcp method is your only option. (And you're still muddying the waters by talking about web browsers. Just say you want a GUI `emacsclient` running on your local machine connected to a remote `emacs` server running on a different machine. Analogies with other technologies will only make it harder for people to understand you. You should instead simply be very specific about what you're trying to achieve with *this* technology.)

There are several approaches to get what you want, from the tame: ssh into the server and use `emacs -nw`; to the exotic: launch PGTK-emacs with the broadway GTK backend and connect to it via a web browser. Which approach to use depends on your particular workflow, but I'll lay out the obvious choices and when to use each. ### pty-emacs As mentioned above, you can ssh from your laptop to your server and launch `emacs -nw` or `emacsclient -t` and be off and running. If you have a truecolor-capable terminal with standard xterm support (`xterm-mouse-mode`), and don't need inline image/pdf support, this is a perfectly workable system, and is the one I usually use. It is able to run on unstable connections (like wifi tethering) and resume dropped connections with minimal disruption. It also needs relatively little network bandwidth. ### X11 forwarding / VNC The second approach is to use X11 forwarding (usually over SSH, which handles the security implications, but direct is also possible) to send the `emacsclient -c` X11 window (frame in emacs terms) to your laptop for drawing. Or you can use vnc/rdp to forward either the server's main display or an X display specific to a running emacs instance. The vnc approach takes slightly more setup, but uses *much* less bandwidth. Also, the X11 version will get you more responsiveness, assuming you're on gigabit networking (even with the screen damage extension, repaining a full 1080p X11 window across the newtork is on the expensive side). Seriously, this is only suitable if you have good networking. ### emacsclient If the laptop and server are both running Linux (window's terminal fails to behave properly), you can launch the emacs server on your server with the socket set to TCP instead of UNIX. Copy the auth token over to your laptop, and you can connect to it via emacsclient by setting `EMACS_SOCKET_NAME` to the correct value (try `man emacsclient` to see how to configure it). Note that while it does basic authentication in the form of a PSK, if you are on an untrusted network, you need to restrict it to listen on `localhost` and forward the port via SSH or anyone can see the network traffic. Anyway, this is commonly used to let low end systems (embedded routers and the like) edit *their* files via emacsclient, as emacsclient will handle sending local files to the server for you, and copying them back on save. Despite that, you can switch to existing buffers once you are connected to the server. Not sure if it lets you easily open new files, but I suspect `eshell` will work for that well enough. ### broadway Last, and probably closest to your "server->webserver->browser" idea, you can get GTK3 with broadway enabled, then run the PGTK version of emacs with the broadway backend set, and connect to it in your browser. I've done that before, and it mostly works. You may find your browser eats some of your key combinations, but the emacs side of things works just fine. But seriously, get yourself a good local terminal (konsole, alacritty, or some other truecolor capable terminal), configure emacs to use truecolor in the terminal, and just ssh in.

thanks for the in-depth reply! * pty-emacs: i can't give up my gui, and the terminal eats too many keystrokes * X11-forwarding: i've never seen it not be too slow.. but i'll give it a try * emacsclient: this is the one i've been trying to get work. i have local emacsclient connected to server emacs right now, and i can make the server open files on its end, but i can't get emacsclient to do anything locally, like open a new frame. $ emacsclient -f <(ssh -p 4200 me@localhost 'cat /tmp/emacs-server-auth/devbox-emacs-server') -c /home/me emacsclient: connected to remote socket at 0.0.0.0 Waiting for Emacs... *ERROR*: Could not open file: /dev/ttys009 any ideas? (i'm accessing the server through a local tunnel at 4200 dont ask... that ssh works and as you can see it does connect) without the -c it works, but like i said, it just opens the file in the running emacs server window (terminal ssh window). * broadway: that doesnt seem like the right approach either. the browser would eat too many shortcuts

What does not work? Anyway, google finds this: https://snarfed.org/emacsclient_in_tramp_remote_shells via ssh port forwarding

interesting article, similar but not quite what i'm after. they want to invoke emacsclient on machine C to open a file on machine C in an emacs instance on machine S i want to invoke emacsclient on machine C to open a file on machine S in an emacs server instance on machine S, through a frame on machine C

So just the inverse of what you are trying to do ….

How many keystrokes the terminal eats depends a lot on the terminal used, but if you look at pdfs/images/anything other than text, or use mixed-size faces, it's an issue. X11-forwarding over a compressed SSH tunnel is often passable, as long as you aren't running too high of a resolution. By "can't get emacsclient to do anything locally", is the goal to edit *local* files? I would assume not, but need to make sure. What are the contents of `/tmp/emacs-server-auth/devbox-emacs-server`? (Blank out the private key). From the looks of it, your local emacsclient is trying to talk to 0.0.0.0, which is not correct. You can also check if `/dev/ttys009` exists and what the permissions on it are. By default, emacsclient in TCP mode expects to still be talking to the same machine it's running on, so if you just had it generate the auth file itself, odds are good it's wrong. And yeah, broadway is neat when you just need remote access in a hurry, but it's kinda limited.

I regularly use remote X11 forwarding, getting emacsclient on my home machine to open its frames on my laptop at my relatives' place on weekends, over pretty ordinary household broadband connections at both ends, with desktop Gnu/Linux running at both ends. It's OK for the limited usage I have then, just checking and updating my Org agenda and doing a little light editing and kicking off occasional background tasks, but I agree it would be frustrating to use as a daily driver. I really like u/perkinslr 's suggestion to use VNC. Think I'm going to try that next time I'm there, probably using x11vnc, which lets me dedicate a whole virtual desktop environment to the single task of displaying Emacs frames.

I believe there are now VNC client/server implementations that support screen damage tracking and h264 encoding, which should be able to manage decent performance, even across the internet.

The server and client process has to be on the same machine. Emacs is not a fully client-server architecture, even when using tcp as the communication system. Source: tried this 10 years ago

the goal is to edit remote files. i assure you that even though it says 0.0.0.0, what it means is the remote machine. i use an ssh tunnel to connect to it and bind some ports locally.

I have been in a similar situation for about two years now, but I have settled on a solution, which does all editing locally, but uses a continuous bidirectional syncing with the remote side. I use unison to perform the sync. It simply runs in the background and watches for changes. I am aware, that this doesn't answer your question the way you posted it, but maybe it's worth looking into. I am happy with this solution, because for all the interactive stuff there is no lag due to the remote connection.

I find it funny that whenever someone asks this question, people like you fail to understand it in hilarious ways. &#x200B; /u/shishkabeb what you are asking isn't supported. People like /u/7890yuiop just never seem to understand it. It's truly amazing, really.

Try Xpra it is much faster than X forwaring . I run Emacs and Xpra in a container \[1\] on my office workstation and connect to it using a VPN from home. &#x200B; \[1\] https://github.com/nakkaya/emacs/

interesting - i'll check that out, thx

that's kind of where i'm at now, but with sone custom jank rsync scripts. i'll have a look at unision, ty

yeah that seems to be the case. thanks for understanding lol. got some good hints at improving workarounds out of this post at least 🤷

I'm certain I'm going to regret this, but... which aspect have I misunderstood?

Apparently nothing. Pretty much what I thought (but sadly not as amazing or hilarious as suggested).