Hacker News Reader

Comment by donio | Hacker News Reader

I bring up remote Emacs frames (from existing sessions, using emacsclient) over ssh forwarded X11 all the time. I prefer this method over tty-only because of the better keyboard support (tty can't pass through all the modifiers or even all the ctrl combinations), image support and clipboard integration. (better colors used to be another reason but less so now that we have 24 bit color support in tty Emacs)

With the fast networks we have nowadays performance is quite good.

I dread the time (if it ever comes) when Wayland takes over to the point that X11 won't be practical to use. And I would use EXWM too which would be even more painful.

View on HN

Have you tried tramp? I routinely use it to edit files on systems without emacs installed. Also you can edit files belonging to root, etc.

Yes, I use tramp as well for all those things. The remote Emacs session is more for everything else I do with Emacs, mail, chat, M-x shell sessions, dev sessions in progress with language servers running, maybe a debugger.

I use tty emacsclient plenty too (including from my phone) and I could certainly manage without remote X11 and perhaps even without EXWM (ouch) but not looking forward to the prospect of losing it, in exchange for... what? Smoother window transitions and scrolling? I don't want my windows to transition, I want jump scroll and things to pop in place instantly. I disable that shit even on Android.

So I guess I will stick with X11 as long as I can and reminisce about better days once it's gone.

(Emacs having its own remote display protocol would be a way to tackle the first part and maybe EXWM could be re-implemented for Wayland somehow too but neither of those things exist today)

> I use tty emacsclient plenty too (including from my phone)

oh my.

You can also expose the Emacs server socket and allow a local native GUI emacsclient to connect to it.

It would be amazing if it worked that way! But I don't think that it does. :(

emacsclient only tells the Emacs session it is talking to to create a new frame, either on an X11 display or on the tty where emacsclient is running. After that emacs does all the work, emacsclient just waits for emacs to tell it that it's done, it takes no active role in actually displaying stuff.

I would love to be wrong on this, please tell me if I am! I would love it if Emacs actually had its own remote display protocol.

Good point -- I haven't tried gnu emacs's X11 driver in ages, so I'll give it another try. Does gnu emacs's X11 display driver finally have a way to keep running after the X connection terminates, and reconnect to a new X server (or multiple X servers at once)?

Under screen, I keep long running emacs sessions with multiple shell buffers running for months and sometimes years, with all the files I'm working on opened up. Each shell buffer might be configured for some branch of some code, with an interactive python or whatever shell running the code connected to the database, with a bunch of useful commands and context in its history. It's a lot of work to recreate all that state.

(Digression: Bash has no way to save and merge and recreate and manage parallel history threads, does it? Or does the last shell that exits just stomp on the one history?).

Back in my Evil Software Hoarder days, I worked on the NeWS display driver for UniPress Emacs 2.20, and later on the NeWS display driver for gnu emacs. Here's a brochure from February 1988 about UniPress Emacs 2.20 and "SoftWire" (NeWS without graphics).

https://www.donhopkins.com/home/ties/scans/WhatIsEmacs.pdf

It supported multiple display drivers (text, X11, NeWS, SunView), as well as multiple window frames on each of those displays (which gnu emacs didn't support at the time), and you could disconnect and reconnect to a long running emacs later. In effect it was a "multi user emacs" since different users could type into multiple displays at the same time (although weird stuff could still happen since the classic Emacs interface wasn't designed for that).

Emacs 2.20 Demo (NeWS, multiple frames, tabbed windows, pie menus, hypermedia authoring):

https://www.youtube.com/watch?v=hhmU2B79EDU

Here are some examples of where the rubber hits the road in NeWS client/server programming of an emacs NeWS display driver. They both download a PostScript file to NeWS that handles most of the user interface, window management, menus, input handling, font measurement, text drawing, etc, and they have a corresponding C driver on the emacs side. There's also a "cps" file that defines the protocol (which is send in tokenized binary instead of plain text), and generates C headers and code stubs. Together they implement an optimized, high level, application specific "emacs protocol" that the client and server use to communicate:

Emacs 2.20 NeWS display driver (supporting multiple tabbed windows and pie menus in the NeWS Lite Toolkit):

https://www.donhopkins.com/home/code/emacs.ps.txt

https://www.donhopkins.com/home/code/TrmPS.c

Gnu Emacs 18 NeWS display driver (supporting a single tabbed windows and pie menus in The NeWS Toolkit 2.0):

https://www.donhopkins.com/home/code/emacs18/src/tnt.ps

https://www.donhopkins.com/home/code/emacs18/src/tnt.c

https://www.donhopkins.com/home/code/emacs18/src/tnt_cps.cps

  % Return the minimum size to keep emacs from core dumping
  %
  /minsize { % - => w h
    /?validate self send
    CharWidth 10 mul Border dup add add
    LineHeight 5 mul Border dup add add
    % XXX: Any smaller and it core dumps!
  } def

Reply on news.ycombinator.com