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).
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).
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):
% 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
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