4 ms·

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 th

by donio 7y ago

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.

m463 7y ago
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.
- donio 7y ago
  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)
  - m463 7y ago
    > I use tty emacsclient plenty too (including from my phone) oh my.
nine_k 7y ago
You can also expose the Emacs server socket and allow a local native GUI emacsclient to connect to it.
- donio 7y ago
  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.
DonHopkins 7y ago
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 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 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/emacs.ps.txt https://www.donhopkins.com/home/code/TrmPS.c 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.ps https://www.donhopkins.com/home/code/emacs18/src/tnt.c https://www.donhopkins.com/home/code/emacs18/src/tnt.c https://www.donhopkins.com/home/code/emacs18/src/tnt_cps.cps 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

by donio 7y ago

m463 7y ago

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.

donio 7y ago
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)
- m463 7y ago
  > I use tty emacsclient plenty too (including from my phone) oh my.

nine_k 7y ago

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

donio 7y ago
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.

DonHopkins 7y ago

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 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 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/emacs.ps.txt https://www.donhopkins.com/home/code/TrmPS.c 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.ps https://www.donhopkins.com/home/code/emacs18/src/tnt.c https://www.donhopkins.com/home/code/emacs18/src/tnt.c https://www.donhopkins.com/home/code/emacs18/src/tnt_cps.cps 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