Emacs in odd places(eigenbahn.com)
eigenbahn.com
Emacs in odd places
https://www.eigenbahn.com/2020/09/02/emacs-in-odd-places
51 comments
+1. For many years I heard strange things from Emacs users about how they wanted to do everything in Emacs. It's just a text editor!
Now I'm one of those strange users. It's not just a text editor.
Now I'm one of those strange users. It's not just a text editor.
I view it more as it being evidence that relying on text interactions is more powerful than folks acknowledge. It can be slower, for dinner things, but usually is more resilient than binary integrations. If only because it is easy to see what it was trying to do.
[deleted]
I love the idea of a huge monolith program that you "live in", although it's contradictory to the popular philosophy "do one thing and do it well". A program that one live in is a perfect example of software as a manifest, in this case a manifest of one's personal digital lifestyle. I hope there's more people doing this, but in a more personal way, however the time and mind commitment required is huge.
I like to think of Emacs more as a platform for a collection of Emacs lisp programs living in a shared process space.
It's not unlike what I've seen of Smalltalk (though I don't use that myself): you wouldn't necessarily think of the Smalltalk VM and image as a huge monolith program.
It's not unlike what I've seen of Smalltalk (though I don't use that myself): you wouldn't necessarily think of the Smalltalk VM and image as a huge monolith program.
Emacs integrates well with Unix software that does one thing and does it well. You can even think of it as a buffering super shell with Lisp programmability, and use it to integrate and automate complicated tasks and put a usable UI on them.
I'm saying it's not because it has stuff like text editor, games even email client built-in (need confirmation never seriously used emacs), if it's only a scripting + text UI engine and offering all other apps as optional plugins then I'd agree it's "doing one thing".
> games even email client built-in
These are plugins which are loaded on demand. So if you never use them, then they are not loaded into the platform.
These are plugins which are loaded on demand. So if you never use them, then they are not loaded into the platform.
I'd say facilities for text editing (buffers, kill rings, etc.) are built in, but nearly everything else -- the different modes for programming languages, games, mail, web, and IRC clients, etc, are all in Emacs Lisp.
My situation is similar but with Vim. I have a comfortable setup
that combines a terminal multiplexer and Vim, and that lets me
do almost anything text-based within the same environment.
In the recent year I also starting doing some of my own custom scripting and syntax files and it's been fun.
Also with Firefox plugins it's possible to use NeoVim as text editing backend on websites which is nice. I'd prefer a lightweight terminal browser for certain use cases, but I haven't found one that can convincingly handle the cluttered web of today. Emacs' eww seems to be more consistent there.
In the recent year I also starting doing some of my own custom scripting and syntax files and it's been fun.
Also with Firefox plugins it's possible to use NeoVim as text editing backend on websites which is nice. I'd prefer a lightweight terminal browser for certain use cases, but I haven't found one that can convincingly handle the cluttered web of today. Emacs' eww seems to be more consistent there.
Which plugins would you recommend for Neovim input in Firefox?
I was using GhostText and enjoyed it very much. Though it stopped working for me and I could never muster the energy to properly look into it. Nowadays I tend to write longer comments in vim and then copy paste to the browser which can be a bit cumbersome.
I was using GhostText and enjoyed it very much. Though it stopped working for me and I could never muster the energy to properly look into it. Nowadays I tend to write longer comments in vim and then copy paste to the browser which can be a bit cumbersome.
I use FireNVim. So far it works exactly as advertised. It could
use one or two more features but overall I like it a lot.
Can you:
- surf the web in vim?
- read/write your email in vim?
- read RSS feeds in vim?
- IRC from vim?
People do these regularly in Emacs.
Emacs just offers a far greater range of things you can do in it than you can in vim.
- surf the web in vim?
- read/write your email in vim?
- read RSS feeds in vim?
- IRC from vim?
People do these regularly in Emacs.
Emacs just offers a far greater range of things you can do in it than you can in vim.
I could do all these things beside Vim in the same terminal
multiplexer instance or within Vim's terminal buffer.
You have to understand that I'm not impressed by the number of features in a program but how it fits my workflow. Emacs just doesn't cut it for me despite multiple attempts, and Vim does.
You have to understand that I'm not impressed by the number of features in a program but how it fits my workflow. Emacs just doesn't cut it for me despite multiple attempts, and Vim does.
Having it beside your editor is just not nearly as good.
It's hard to get across how great it is to have everything you use totally integrated in to one system, and everything programmable and extensible in the same easy and powerful language that the whole integrated system uses, as Emacs does with all of its packages in Lisp.
A tightly integrated system minimizes mental context switching and having to deal an hodgepodge of different languages, configuration systems, and help systems.
To extend or fix an Emacs package, I don't have to jump down in to C for one thing, Python for another, Rust for another, OCaml or Haskell of another, and Javascript for yet another. It's a rare person who knows all of these languages and is expert enough in them to be able to tweak, modify or extend all the applications they use that are written in them.
In Emacs you just have to know Lisp, and all of the applications written for Emacs are open to you.
That's hugely powerful.
If you want these Emacs applications to behave a different way or integrate in to your setup in a different way from how they were designed, that's super easy to do compared to doing the same thing outside of Emacs, and the workflow you can develop in a system that you designed to be just the way you want can be extremely streamlined and efficient.
I'm sorry to hear that trying Emacs hasn't worked out for you. I'll just say that I used vi and vim for decades before switching to Emacs, and while it did take a lot of work to set up Emacs the way I wanted, in a very vim-like fashion using Evil, it was very much worth it, and now my Emacs setup could do many things that my vim setup never could and probably never will.
It's hard to get across how great it is to have everything you use totally integrated in to one system, and everything programmable and extensible in the same easy and powerful language that the whole integrated system uses, as Emacs does with all of its packages in Lisp.
A tightly integrated system minimizes mental context switching and having to deal an hodgepodge of different languages, configuration systems, and help systems.
To extend or fix an Emacs package, I don't have to jump down in to C for one thing, Python for another, Rust for another, OCaml or Haskell of another, and Javascript for yet another. It's a rare person who knows all of these languages and is expert enough in them to be able to tweak, modify or extend all the applications they use that are written in them.
In Emacs you just have to know Lisp, and all of the applications written for Emacs are open to you.
That's hugely powerful.
If you want these Emacs applications to behave a different way or integrate in to your setup in a different way from how they were designed, that's super easy to do compared to doing the same thing outside of Emacs, and the workflow you can develop in a system that you designed to be just the way you want can be extremely streamlined and efficient.
I'm sorry to hear that trying Emacs hasn't worked out for you. I'll just say that I used vi and vim for decades before switching to Emacs, and while it did take a lot of work to set up Emacs the way I wanted, in a very vim-like fashion using Evil, it was very much worth it, and now my Emacs setup could do many things that my vim setup never could and probably never will.
vi has never held the concentric view of life lisp thus emacs did.
IMHO using Emacs as your X window manager isn't particularly strange -- conceptually at least, it seems more natural than the Chromebook model, where people are essentially using a web browser as a window manager.
Picked up doom-emacs last month for org-mode, and am slowly getting into it. Then a couple of weeks ago started using beancount, with the emacs mode.
So far I'm still far more comfortable in vim and the terminal -- even, for instance, switching back to my terminal to do `bean-check` rather than doing it within emacs itself. I could see myself keeping my use of emacs pretty limited like this indefinitely, and still finding it useful - I'm unlikely to give up these uses of emacs. Maybe over a long enough time horizon emacs will feel a bit less strange to me and I'll find more places it fits a niche, or maybe not. Either way, it's a nice addition to my tool set, and I'll be curious to see where I land with in in a year or so.
So far I'm still far more comfortable in vim and the terminal -- even, for instance, switching back to my terminal to do `bean-check` rather than doing it within emacs itself. I could see myself keeping my use of emacs pretty limited like this indefinitely, and still finding it useful - I'm unlikely to give up these uses of emacs. Maybe over a long enough time horizon emacs will feel a bit less strange to me and I'll find more places it fits a niche, or maybe not. Either way, it's a nice addition to my tool set, and I'll be curious to see where I land with in in a year or so.
You'll probably want to look into using Emacs as a server. Emacs creeps up on you, you'll be surprised looking back on this comment in a year.
In Emacs, add (start-server) to your config. Then in your shell rc file:
alias vim='emacsclient -a/usr/bin/vim -nw'
Now if emacs is running you'll get emacs in the terminal when you use the command vim to open a file. If it's not running, vim opens it instead.
Super slick for converts from the vim workflow
alias vim='emacsclient -a/usr/bin/vim -nw'
Now if emacs is running you'll get emacs in the terminal when you use the command vim to open a file. If it's not running, vim opens it instead.
Super slick for converts from the vim workflow
I think using the `--daemon` flag is better. Especially because you can then name the server session. I do this with an unnamed daemon for general use, but a project or language name for other efforts. It helps keep my configurations and buffers cleanly separated based on context.
When I started using Unix in '85 or so I didn't find it especially user friendly so the first program I wrote was a little trampoline alternative to the login shell (/bin/sh in those days) that exec'd emacs as the terminal's controlling process. At least that way I could be an a more familiar environment.
My emacs init checked argv[0] -- if the name started with '-' then it asked if I intended to log out before exiting.
That was on the original GNU machine -- yes, when the FSF's entire computing resource was an unused VAX 750 that nobody wanted and that had been purchased and installed by someone unknown for reasons also unknown and was just taking up space in a small machine room.
My emacs init checked argv[0] -- if the name started with '-' then it asked if I intended to log out before exiting.
That was on the original GNU machine -- yes, when the FSF's entire computing resource was an unused VAX 750 that nobody wanted and that had been purchased and installed by someone unknown for reasons also unknown and was just taking up space in a small machine room.
> When I started using Unix in '85 or so I didn't find it especially user friendly so the first program I wrote was a little trampoline alternative to the login shell (/bin/sh in those days) that exec'd emacs as the terminal's controlling process. At least that way I could be an a more familiar environment.
Interesting how things get reinvented every so often:
https://en.wikipedia.org/wiki/ORVYL_and_WYLBUR
> The names ORVYL and WYLBUR are often used interchangeably, but:
> ORVYL is a timesharing monitor that supports a file system, command language, program execution and debugging, and provides supervisor services.[1]
> WYLBUR is a text editor, word processor,[a] job submission and retrieval, and e-mail program designed to work in conjunction with ORVYL or with IBM's OS/360, SVS, and MVS operating systems.[2] and
> MILTEN is terminal control software used by both ORVYL and WYLBUR for start/stop terminals.[1]
> WYLBUR is not a full standalone operating system in the mold of Dartmouth Time Sharing System (DTSS) or Unix. Instead it runs on top of an IBM batch operating system (OS/360, SVS, MVS). It takes the form of an editor with a Remote Job Entry system and thus has much the same relationship to the IBM operating systems as Emacs does to Unix. For these reasons WYLBUR is often thought of as a text editor rather than a time-sharing system. However, whereas Unix does not need Emacs to provide text editing services, IBM's operating systems originally needed WYLBUR. Later innovations such as IBM's Time Sharing Option (TSO) made WYLBUR less relevant for IBM users and gradually replaced it.
[snip]
> ORVYL and WYLBUR first became available in 1967–68, before TSS/360, TSO, or any other official time-sharing solution from IBM. This was roughly the same time that third-party time-sharing systems such as MTS became available and the under the radar development effort of CP-67 at IBM's own Cambridge Scientific Center took place. WYLBUR had the additional advantage that it could be used in conjunction with IBM's mainstream operating system, OS/360.
"Text editor as a primary user interface" is a design idea which pops up every so often. People pushing modern Emacs into being their widow manager (exwm) is a new reinvention.
Interesting how things get reinvented every so often:
https://en.wikipedia.org/wiki/ORVYL_and_WYLBUR
> The names ORVYL and WYLBUR are often used interchangeably, but:
> ORVYL is a timesharing monitor that supports a file system, command language, program execution and debugging, and provides supervisor services.[1]
> WYLBUR is a text editor, word processor,[a] job submission and retrieval, and e-mail program designed to work in conjunction with ORVYL or with IBM's OS/360, SVS, and MVS operating systems.[2] and
> MILTEN is terminal control software used by both ORVYL and WYLBUR for start/stop terminals.[1]
> WYLBUR is not a full standalone operating system in the mold of Dartmouth Time Sharing System (DTSS) or Unix. Instead it runs on top of an IBM batch operating system (OS/360, SVS, MVS). It takes the form of an editor with a Remote Job Entry system and thus has much the same relationship to the IBM operating systems as Emacs does to Unix. For these reasons WYLBUR is often thought of as a text editor rather than a time-sharing system. However, whereas Unix does not need Emacs to provide text editing services, IBM's operating systems originally needed WYLBUR. Later innovations such as IBM's Time Sharing Option (TSO) made WYLBUR less relevant for IBM users and gradually replaced it.
[snip]
> ORVYL and WYLBUR first became available in 1967–68, before TSS/360, TSO, or any other official time-sharing solution from IBM. This was roughly the same time that third-party time-sharing systems such as MTS became available and the under the radar development effort of CP-67 at IBM's own Cambridge Scientific Center took place. WYLBUR had the additional advantage that it could be used in conjunction with IBM's mainstream operating system, OS/360.
"Text editor as a primary user interface" is a design idea which pops up every so often. People pushing modern Emacs into being their widow manager (exwm) is a new reinvention.
Indeed, I started using EMACS under ITS, a timesharing OS from the early 60s, whose command “shell” was the debugger. This of course influenced the Lispm, and the GNU philosophy.
> for many Emacs users, it's just plain fun
That's what I've come to realize, which is why I don't think I'll ever use emacs. For me, the effort involved would be very not-fun: I just want a tool that works, with a minimum of ongoing effort and mental overhead. If emacs could be made to fit that, I'd go for it.
That's what I've come to realize, which is why I don't think I'll ever use emacs. For me, the effort involved would be very not-fun: I just want a tool that works, with a minimum of ongoing effort and mental overhead. If emacs could be made to fit that, I'd go for it.
This reminds me of the story Steve Yegge told about Emacs powering Amazon's customer service for years:
> Mailman was the Customer Service customer-email processing application for ... four, five years? A long time, anyway. It was written in Emacs. Everyone loved it.
> People still love it. To this very day, I still have to listen to long stories from our non-technical folks about how much they miss Mailman. I'm not shitting you. Last Christmas I was at an Amazon party, some party I have no idea how I got invited to, filled with business people, all of them much prettier and more charming than me and the folks I work with here in the Furnace, the Boiler Room of Amazon. Four young women found out I was in Customer Service, cornered me, and talked for fifteen minutes about how much they missed Mailman and Emacs, and how Arizona (the JSP replacement we'd spent years developing) still just wasn't doing it for them.
https://sites.google.com/site/steveyegge2/tour-de-babel#TOC-...
> Mailman was the Customer Service customer-email processing application for ... four, five years? A long time, anyway. It was written in Emacs. Everyone loved it.
> People still love it. To this very day, I still have to listen to long stories from our non-technical folks about how much they miss Mailman. I'm not shitting you. Last Christmas I was at an Amazon party, some party I have no idea how I got invited to, filled with business people, all of them much prettier and more charming than me and the folks I work with here in the Furnace, the Boiler Room of Amazon. Four young women found out I was in Customer Service, cornered me, and talked for fifteen minutes about how much they missed Mailman and Emacs, and how Arizona (the JSP replacement we'd spent years developing) still just wasn't doing it for them.
https://sites.google.com/site/steveyegge2/tour-de-babel#TOC-...
I've read this story countless time, and after having worked in a few places, I realize that software being missed is quite rare.
[deleted]
I once wrote a patch to Emacs to make it possible to build it as part of buildroot. The problem here is that buildroot does cross-compiling, and Emacs has no native support for cross-building. However, qemu was able to help by emulating the target arch at user-space level (I didnt even know this worked, very nice). I am not sure if that hack still works today, since the Emacs dumper was recently rewritten AFAIK.
Regarding Emacs being an universal UI platform, I wrote a metapost to emacs-devel to celebrate that fact very recently. Indeed, Emacs is the only platform I know which can be used to write programs which work on the terminal and with a GUI toolkit alike. I call that modality-independant.
https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00...
Regarding Emacs being an universal UI platform, I wrote a metapost to emacs-devel to celebrate that fact very recently. Indeed, Emacs is the only platform I know which can be used to write programs which work on the terminal and with a GUI toolkit alike. I call that modality-independant.
https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00...
Wow, impressed by that buildroot port. Did you had any particular target hardware when doing this?
I see we share a similar view of what Emacs really is (https://www.eigenbahn.com/2020/01/12/emacs-is-no-editor) and enjoyed your piece. Thanks for posting it.
Having the possibility to have a system that "glues" together different functionalities in a coherent way is really something.
And you being a blind person, I can only conceive how even more critical that is.
I see we share a similar view of what Emacs really is (https://www.eigenbahn.com/2020/01/12/emacs-is-no-editor) and enjoyed your piece. Thanks for posting it.
Having the possibility to have a system that "glues" together different functionalities in a coherent way is really something.
And you being a blind person, I can only conceive how even more critical that is.
What I mostly get from this is, that there really is no good modern alternative to those great UMPCs.
Of course there is! The GPD family of Windows devices (Win/Win2/Win Max and Pocket/Pocket 2/Pocket2 Max) have pretty good hardware and somewhat decent linux support (they all have official Ubuntu Mate images), and the GPD MicroPC even has quite a few ports more than a modern ultrabook (ethernet, full size usb, 3.5' jack, even a RS232!). They have price points ranging from 400$ to 1000$, so there's something for everyone as well.
Disclaimer: While I don't work for GPD I'm a very happy owner of a Win 2 that I use for light gaming and game streaming with Stadia and Geforce Now, and I've started using it for "computery tasks" more and more as I just keep that and my iPad Pro in my backpack - not that I leave the house often these days, though...
Disclaimer: While I don't work for GPD I'm a very happy owner of a Win 2 that I use for light gaming and game streaming with Stadia and Geforce Now, and I've started using it for "computery tasks" more and more as I just keep that and my iPad Pro in my backpack - not that I leave the house often these days, though...
I have a Gemini PDA, and it's not bad. I could wish for an X server to run Emacs against, but it works fine in terminal mode; I could wish for a more comfortable Linux-on-metal experience, but Termux and Firefox on Android are easily good enough. The keyboard is excellent.
Too bad it came along a decade after I ceased to really need the kind of road-warrior sysadmin capability that such a device excels at providing. I'm still glad to have it.
Too bad it came along a decade after I ceased to really need the kind of road-warrior sysadmin capability that such a device excels at providing. I'm still glad to have it.
Emacs clone “AMIS” for TOPS-10 (swedish):
https://hack.org/mc/texts/amis.txt
https://hack.org/mc/texts/amis.txt
Oh yeah, I used to run Emacs+org-mode on an N900. Nowadays I run it in Termux. Fits my needs.
N900 had such a beautiful keyboard. I learned C and Python with ease from it,
and wrote several fanfics - all enabled by the sheer ease of being able to slide open that keyboard (with the satisfying click) and precision typing a paragraph with what to the outside world must have looked like a series of well-timed squeeze-rubbing motions.
I could type blind too - talking and interacting with someone whilst finishing a sentence with my other hand brain. I miss it so much.
I could type blind too - talking and interacting with someone whilst finishing a sentence with my other hand brain. I miss it so much.
Hi, I'm the original author of the article.
I'm quite surprised to see this got posted and made it to the front page.
I'm a bit late to the party.
Don't hesitate to ask questions, though.
I'm quite surprised to see this got posted and made it to the front page.
I'm a bit late to the party.
Don't hesitate to ask questions, though.
> It’s common sense that almost every device with a bare minimum of computing power can run Doom.
Oh how far we've come since '93.
Oh how far we've come since '93.
I have been a Vim user for as far as I can remember. Now I am transitioning to Emacs. I keep hearing that you can "live" in emacs but I can't seem to have that revelation, yet.
For example, I often find myself quit Emacs to jump to a different directory just to open a file. I think I am doing this wrong. I have tried Dire/Neotree but those are not providing enough convenience imo.
Do you you a workflow or setup to "live" in emacs? Note: I use pure Emacs and not spacemac or Doom.
For example, I often find myself quit Emacs to jump to a different directory just to open a file. I think I am doing this wrong. I have tried Dire/Neotree but those are not providing enough convenience imo.
Do you you a workflow or setup to "live" in emacs? Note: I use pure Emacs and not spacemac or Doom.
You can navigate to files in Emacs using `find-file` (C-x C-f with standard key bindings).
That should prompt you to enter a path, which, without any customization, should perform very similar to a shell prompt in terms of using tab for file completions.
A huge improvement to this in my opinion is the use of a completion framework package. I use ivy[0] but helm is also popular and there are others.
The main draw in this case is instead of having to tab through completion candidates, they appear as a vertical list which is updated as you type. It also allows more advanced filtering, for example by regex which I find a lot easier to use than shell completion which only supports prefix.
For example say I want to navigate to a directory called `the-project` but I always forget whether it's named `the-project` or `a-project`, it doesn't matter because I just type `project` and would see `the-project` as an option so I'd navigate to that and select it (using `C-n` and `C-p` to navigate the list).
If that isn't what you're looking for then another option is `emacsclient` [1] which let's you open files in an already existing Emacs process.
[0] https://github.com/abo-abo/swiper
[1] https://www.emacswiki.org/emacs/EmacsClient
That should prompt you to enter a path, which, without any customization, should perform very similar to a shell prompt in terms of using tab for file completions.
A huge improvement to this in my opinion is the use of a completion framework package. I use ivy[0] but helm is also popular and there are others.
The main draw in this case is instead of having to tab through completion candidates, they appear as a vertical list which is updated as you type. It also allows more advanced filtering, for example by regex which I find a lot easier to use than shell completion which only supports prefix.
For example say I want to navigate to a directory called `the-project` but I always forget whether it's named `the-project` or `a-project`, it doesn't matter because I just type `project` and would see `the-project` as an option so I'd navigate to that and select it (using `C-n` and `C-p` to navigate the list).
If that isn't what you're looking for then another option is `emacsclient` [1] which let's you open files in an already existing Emacs process.
[0] https://github.com/abo-abo/swiper
[1] https://www.emacswiki.org/emacs/EmacsClient
If you used Ranger in your vim days it's also available in emacs. Projectile when inside a git repo also has a lot of good stuff for navigation, see projective-find-file and other fn from the package.
I will leave this here for the small set of people that use both emacs and windows. The 'everything' extension for emacs is really great, instant HD(s) wide file/folder search. If you don't have Everything.exe installed on your windows machine i'd urge you to go try it. (with or without emacs) As far as emacs integration this is what I use for it. The 2nd function requires the projectile and perspective extensions, it opens a new virtual-desktop-thing inside emacs.
I will leave this here for the small set of people that use both emacs and windows. The 'everything' extension for emacs is really great, instant HD(s) wide file/folder search. If you don't have Everything.exe installed on your windows machine i'd urge you to go try it. (with or without emacs) As far as emacs integration this is what I use for it. The 2nd function requires the projectile and perspective extensions, it opens a new virtual-desktop-thing inside emacs.
(if (eq system-type 'windows-nt)
(use-package everything
:config
(setq everything-cmd "C:\\Program Files\\Everything\\es.exe")
(setq everything-ffap-integration nil)))
(defun open-file-from-anywhere ()
(interactive)
(everything))
(defun open-file-from-anywhere-in-new-persp-if-in-project ()
(interactive)
(let* ((fpath (everything-find-prompt))
(f-projectile-root (projectile-project-root fpath))
(project-name (projectile-project-name f-projectile-root)))
(if f-projectile-root
(progn
(persp-switch project-name)
(find-file fpath))
(progn
(message "File is not in a valid project directory")
(find-file fpath)))))There is a special mode for looking for files called "Dired". It is very powerful, especially with the extensions. This link is a good introduction to it:
http://pragmaticemacs.com/emacs/dired-marking-copying-moving...
http://pragmaticemacs.com/emacs/dired-marking-copying-moving...
In addition to the other suggestions, you probably want to run Emacs as a daemon so you raise and destroy emacsclients without having to quit. You also may want to run GUI emacs rather than terminal emacs (it has a variety of advantages).
emacs in termux on any android device
With an external bluetooth keyboard, this solution is surprisingly good. This is what I use for light remote work when I go on leisure travel and don't want to bring my laptop.
even text scrolling by touch works for me. hackers keyboard on android is a godsent. also you can install it without the play store by downloading the apk directly from f-droid. works on a fire hd like a charm. combine that with floatingapps.net and you even can use it in an x-windows style.
I recently saw a TikTok from a (I believe) non technical Mac user describing how to use the Doctor/Eliza bot to save on therapy. I was pretty impressed!
Yow! Legally-imposed CULTURE-reduction is CABBAGE-BRAINED!
[deleted]
Just to give an alternative perspective, I use emacs almost exclusively in the terminal through SSH. It is very convenient to be able to SSH into a host running emacs daemon and immediately have access to my existing session doing everything from irc and email, to editing scripts and tex files. X11 forwarding would be too sluggish and things like tramp don't keep you connected to irc. I do accept though that emacs in the GUI is probably how the majority of users are using it, so not moaning, just giving perhaps an alt use case.
I recognize that the practical arguments in favor of doing this are limited at best. Sometimes people "Emacs evangelize" by talking about how living entirely within the program allows them to have one text editing paradigm for everything in their lives; even though that is indeed nice, non-users aren't wrong to be skeptical about the practical benefits, given the amount of effort that will probably be involved. The secret is that for many Emacs users, it's just plain fun -- hence the things shown in this article, and also EXWM.
[1] https://github.com/ch11ng/exwm