20+ years of Emacs
I enjoyed reading this article named "22 years of Emacs" recently. It's kind of fascinating, because I realised I don't exactly know for how long I've been using Emacs. It's lost in the mists of history. If I would have to venture a guess, it was back in the "early days", which in that history is mapped around 1996-1997, when I installed my very own "PC" with FreeBSD 2.2.x and painstakingly managed to make XFree86 run on it.
Modelines. Those were the days... But I digress.
I am old...
The only formal timestamp I can put is that my rebuilt .emacs.d git repository has its first commit in 2002. Some people reading this may be born after that time. This means I'm at least significantly older than those people, to put things gently.
Clever history nerds will notice that the commit is obviously fake: Git itself did not exist until 2005. But ah-ah! I was already managing my home directory with CVS in 2001! I converted that repository into git some time in 2009, and therefore you can see all my embarrassing history, including changes from two decades ago.
That includes my first known .emacs file which is just bizarre to read right now: 200 lines, most of which are "customize" stuff. Compare with the current, 1000+ lines init.el which is also still kind of a mess, but actually shares very little with the original, thankfully.
All this to say that in those years (decades, really) of using
Emacs, I have had a very different experience than credmp who wrote
packages, sent patches, and got name dropping from other
developers. My experience is just struggling to keep up with
everything, in general, but also in Emacs.
... and Emacs is too fast for me
It might sound odd to say, but Emacs is actually moving pretty fast right now. A lot of new packages are coming out, and I can hardly keep up.
I am not using org mode, but did use it for time (and task) tracking for a while (and for invoicing too, funky stuff).
I am not using mu4e, but maybe I'm using something better (notmuch) and yes, I am reading my mail in Emacs, which I find questionable from a security perspective. (Sandboxing untrusted inputs? Anyone?)
I am using magit, but only when coding, so I do end up using git on the command line quite a bit anyways.
I do have which-key enabled, and reading about it reminded me I wanted to turn it off because it's kind of noisy and I never remember I can actually use it for anything. Or, in other words, I don't even remember the prefix key or, when I do, there's too many possible commands after for it to be useful.
I haven't setup lsp-mode, let alone Eglot, which I just learned about reading the article. I thought I would be super shiny and cool by setting up LSP instead of the (dying?) elpy package, but I never got around to it. And now it seems lsp-mode is uncool and I should really do eglot instead, and that doesn't help.
UPDATE: I finally got tired and switched to
lsp-mode. See this post for details.I am not using projectile. It's on some of my numerous todo lists somewhere, surely. I suspect it's important to getting my projects organised, but I still live halfway between the terminal and Emacs, so it's not quite clear what I would gain.
Update: I also started using projectile, but I'm not sure I like it.
I had to ask what native compilation was or why it mattered the first time I heard of it. And when I saw it again in the article, I had to click through to remember.
Overall, I feel there's a lot of cool stuff in Emacs out there. But I
can't quite tell what's the best of which. I can barely remember which
completion mechanism I use (company, maybe?) or what makes my
mini-buffer completion work the way it does. Everything is lost in
piles of customize and .emacs hacks that is constantly
changing. Because a lot is in third-party packages, there are often
many different options and it's hard to tell which one we should be
using.
... or at least fast enough
And really, Emacs feels fast enough for me. When I started, I was running Emacs on a Pentium I, 166MHz, with 8MB of RAM (eventually upgraded to 32MB, whoohoo!). Back in those days, the joke was that EMACS was an acronym for "Eight Megs, Always Scratching" and now that I write this down, I realize it's actually "Eight Megs, and Constantly Swapping", which doesn't sound as nice because you could actually hear Emacs running on those old hard drives back in the days. It would make a "scratching" noise as the hard drive heads would scramble maniacally to swap pages in and out of swap to make room for the memory-hungry editor.
Now Emacs is pretty far down the list of processes in top(1)
regardless of how you look at it. It's using 97MB of resident memory
and close to 400MB of virtual memory, which does sound like an awful
lot compared to my first computer... But it's absolutely nothing
compared to things like Signal-desktop, which somehow manages to
map a whopping 20.5GB virtual memory. (That's twenty Gigabytes of
memory for old timers or time travelers from the past, and yes, that
is now a thing.) I'm not exactly sure how much resident memory it uses
(because it forks multiple processes), probably somewhere around 300MB
of resident memory. Firefox also uses gigabytes of that good stuff,
also spread around the multiple processes, per tab.
Emacs "feels" super fast. Typing latency is noticeably better in Emacs than my web browser, and even beats most terminal emulators. It gets a little worse when font-locking is enabled, unfortunately, but it's still feels much better.
And all my old stuff still works in Emacs, amazingly. (Good luck with your old Netscape or ICQ configuration from 2000.)
I feel like an oldie, using Emacs, but I'm really happy to see younger people using it, and learning it, and especially improving it. If anything, one direction I would like to see it go is closer to what web browsers are doing (yes, I know how bad that sounds) and get better isolation between tasks.
An attack on my email client shouldn't be able to edit my Puppet code, and/or all files on my system, for example. And I know, fundamentally, that's a really hard challenge in Emacs. But if you're going to treat your editor as your operating system (or vice versa, I lost track of where we are now that there's an Emacs Window Manager, which I do not use), at least we should get that kind of security.
Otherwise I'll have to find a new mail client, and that's really something I try to limit to once a decade or so.
Hi, I really enjoyed this article!
Interestingly something the Debian Emacsen Team convinced me of is (to summarise my understanding): Don't worry, backwards compat is integral to Emacs culture, and deprecation happens slowly, so Emacs is a good investment of time. I had already decided that it was probably the most future-proof solution, and it was only a question of assessing how much maintenance work would be required.
Is lsp-mode uncool?
lsp-mode=98th percentile vs eglot's 89th,
https://stable.melpa.org/#/lsp-mode https://stable.melpa.org/#/eglot
plus allegedly still more interest, growth, and activity,
https://www.libhunt.com/compare-eglot-vs-lsp-mode
In 2020 eglot didn't work with TRAMP (I'm not sure if it does now)
https://www.reddit.com/r/emacs/comments/do2z6y/i_am_moving_from_lspmode_to_eglot/f5jyury/?utm_source=reddit&utm_medium=web2x&context=3
It also sounds like lsp-mode is easier to get working, but that said, if your UI and workflow preferences are still the same as I remember they are, then you'll probably feel like disabling a bunch of stuff in lsp-mode. If TRAMP compatibility isn't important, then maybe you'd enjoy testing eglot more?
Re: projectile, I wonder if Emacs 27's project.el will be able to catch up?
Re: buffer isolation and security, I think this is currently still blocked by lack of "real/proper" threading. If Emacs 28 has these then I'll agree that a big change has occurred, otherwise I think we're still using an editor that is layers of abstraction away from an emulation of a single-threaded 1970s LISP machine :-p
https://www.reddit.com/r/emacs/comments/oclycy/is_emacs_multi_threaded_presently/ https://www.reddit.com/r/emacs/comments/n13v5l/what_is_the_next_big_feature_after_native_comp/
... at least I like to think he's older, otherwise I would be even more jealous. Check this shit out:
https://gwolf.org/2022/03/long-long-long-live-emacs_after_39_years.html
I'd be interested to read what solution you envision to the "sandboxing untrusted input" challenge. I am not convinced that using a separate MUA is all that compelling.
I do see an issue with Emacs (Magit) requiring direct access to ".git" rather than just do all business in ".git" via git-client, This means that I can;t effectively block Emacs from manipulating the git metadata and thus the integrity of my source codes but other than that practically speaking (and besides that is not Gnus fault I believe that a functional MUA needs fairly broad access (attachments, post processing of e-mails)
I am a Emacs/Gnus user myself and I use SELinux to enforce at least some integrity when it comes to Emacs (and the user session in general)
Hi dac.override, thanks for your comment and welcome here!
The challenge is that, typically, on a UNIX system, process A cannot read memory from process B. You can break that with a debugger, for example, but it's possible to disable that as well. Web browsers also sandbox their processes so that tab A can't read from tab B as well.
In other words, normally, a mail client (say
mutt) cannot start editing my files. I can even write apparmor files that keep it from doing so at the kernel level.I can't do that with Emacs, because it's a single process which does everything. This means that if there's a compromise anywhere in my email client stack (and that stack is deep: message-mode, gnus, notmuch-emacs, notmuch...), then I can easily get attacked.
Yes, but that access can be scoped quite restrictively. For example, my mail client should be able to access the
notmuchbinary (or its shared libraries, if it's fancier) and only myMaildirfolder, and nothing else.I am deeply curious how you can manage that at all. Here I need Emacs to access all my files and basically start any process, not sure how I would sandbox it in any way?
Thanks.
There are always trade-offs involved but here are two examples of how I (try to) enhance integrity of Emacs with SELinux.
Only gnupg clients (and I guess your login shell) should (ideally) ever access "GNUPGHOME" and the various sock files etc. Emacs has GPG support but it (AFAIK) always runs Gnupg. By allowing Emacs to run Gnupg with what is called a "domain transition" from Emacs' "domain" to the Gnupg "domain you can effectively tell Linux that only Gnupg should ever be able to access the aforementioned. That enhances integrity because now the Emacs "domain" no longer needs permissions to access Gnupg related entities.
Same with for example SSH (things like Tramp/Git). Only SSH clients (and I guess your login shell) should ever access ~/.ssh. You can enforce a "domain transition" from the Emacs domain to the SSH client domain and tell Linux that only the SSH client domain should ever be able to access ~/.ssh. Emacs can execute the SSH client but ".ssh" can only be accessed from SSH client domain (and thus effectively only by the SSH client).
This is generally also how I enforce integrity of my Git repositories. I simply have a domain associated with the Git clients and tell SELinux that only the Git client domain should ever be able to access ".git" metadata. But that obviously only works if all access to ".git" goes via the Git client (and Magit needs some direct access and since that is Emacs' domain that means I would have to associate those permissions with the Emacs domain.
(it gets a bit more complicated though since Emacs eventually needs to be able to execute a shell on your behalf (M-x shell etc), and you probably want to be able to access GNUPGHOME from your shell)
The thing with other more "generic" content is that it usually needs to be "shareable". That for example your ~/Documents. You might want to edit a document with Emacs. You might want to be able to read or store attachments from ~/Documents. So effectively both the Emacs domain as well as for example any MUA domain effectively needs access to "shareable" content.
From that perspective it does not really matter whether you run Gnus or a external mail client (they both probably need access to "generic" content)
This is what my Emacs SELinux security policy looks like:
https://git.defensec.nl/?p=dssp5.git;a=blob;f=src/agent/useragent/e/emacs.cil;h=ab2c0af79f5f8bc0473ae843d86ee8e9b96d00d8;hb=refs/heads/dssp5-debian
Keep in mind though that there are always trade-offs to be made, but the same goes for many other applications. Even something like Firefox needs fairly broad access. You want to be able to read and write ~/Downloads for example (but you dont want it accessing ~/.gnupg, ~/.ssh, ~/Workspace/mystuff/.git or any other stuff that it should not have access to in any case.
The difference between using SELinux versus built-in security, amongst other things, is that SElinux just relies on a safe kernel whereas built-in security relies on the implementation itself and eventually you still need a safe kernel anyway.
I am not saying that Emacs should not be working to improve security though. Just saying that both Emacs and Mutt probably need access to ~/Downloads eventually and they both probably need to be able to execute scripts on your behalf. From that perspective (at least) might as well run it in the same process.