The bar for being important enough to not discard when it works and is the only solution to particular problems is not very high.
I know of no other method to forward individual programs GUIs to other machines. Abandoning X is abandoning a power we have.
You're right that it may not be used as much. Last time I used it was to debug why selenium tests running in chrome were failing in a server with a virtual display (Xvfb) when the tests would work in any developer's machine. I forwarded chrome's GUI from a docker container in a server in another room via my development machine. Its window was neatly tiled next to my other windows in my tiled window manager. You wouldn't be able to tell it wasn't running locally. I don't have to mess around with a desktop inside a desktop. Such neatness in UX is a comfort I'd like to keep.
I'm all for making a new, more efficient display server, but please don't take powers away.
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.
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)
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).
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
Well, no one that matters anyway. For values of "matter" equivalent to "uses a modern desktop".
Whatever the case, modern development heavily favors coding for the common case, not supporting a flexible framework that can accommodate fringe cases. And in 2019, your use case is fringe.
If you abandon every feature a handful of users think nobody uses on any piece of complex software you will end up removing something that everyone uses.
People with opinions like yourself are why gnome software developers removed gui functionality for managing raid arrays from gnome disks with the explanation that people should just use btrfs or zfs. This left you with an easy gui to create a raid array that you wont be able to fix without learning cli tools.
At the time you couldn't insofar as I'm aware in the installer create a zfs or btrfs raid in 2014. Further reports of btrfs eating data were still disturbingly common and zfs wasn't in anyones official repos.
Regarding the "modern" desktop
"That might have been so if he had lived a few centuries earlier. At that time the humans still knew pretty well when a thing was proved and when it was not; and if it was proved they really believed it. They still connected thinking with doing and were prepared to alter their way of life as the result of a chain of reasoning. But what with the weekly press and other such weapons we have largely altered that. Your man has been accustomed, ever since he was a boy, to have a dozen incompatible philosophies dancing about together inside his head. He doesn't think of doctrines as primarily "true" of "false", but as "academic" or "practical", "outworn" or "contemporary", "conventional" or "ruthless". Jargon, not argument, is your best ally in keeping him from the Church. Don't waste time trying to make him think that materialism is true! Make him think it is strong, or stark, or courageous--that it is the philosophy of the future. That's the sort of thing he cares about."
> Whatever the case, modern development heavily favors coding for the common case, not supporting a flexible framework that can accommodate fringe cases. And in 2019, your use case is fringe.
Are you going to say that accessibility features should also be discarded? Being deaf or blind are not the common case.
"Modernity", "network transparency is irrelevant in $CURRENT_YEAR" and "nobody uses those features anymore" are among the most commonly cited reasons why you must abandon X NOW and switch to Wayland. Those and "muh security". (The very real security issues with Xorg could be mitigated or eliminated completely with a more sophisticated X server design.)
Like it or not, you will have to come to grips with the fact that the Linux desktop and graphics-stack discussion is dominated by developers from the age of GNOME, who haven't put much thought in beyond how they personally use their own MacBooks. These are the ones calling the shots, and they've decided that X is obsolete, that network transparency is cruft that should be eliminated, and that Wayland is suited to task. So Wayland will be the supported solution going forward.
> Are you going to say that accessibility features should also be discarded? Being deaf or blind are not the common case.
Given the shit state of accessibility under Linux, I'd say yes, it is fringe to the people building the Linux desktop. If you're disabled, it makes much more sense to get a Mac or Windows machine.
Remote Xorg is the easiest way to get GUI applications running under WSL on Windows. That's the only recent relevant application I've come across though.
