I have been using Emacs for more than 30 years now. Other editors have come and gone, Emacs stayed. Parts of my configuration are more than 30 years old.
There were better and worse times in Emacs history. Recent times, however, are really good. Emacs is maintained and developed actively and there are many external packages which are impressive. Magit and ghostel are good examples of packages that I use on a daily basis to get my work done.
Recently, AI completely changed how I use Emacs, and in a very good way. I now treat AI as a fairy that can fulfill any wish. I describe how I want my editor to work, and boom! it works that way.
Examples: window and tab management, difftastic integration, markdown previews with beautifully rendered tables, markdown previews as PDFs, and many more.
What is most important, however, goes back to Stallman's original ideas. I am in control of my editor and my environment. I decide how it will look and behave. No corporation decides for me. No corporation builds in a new AI assistant. Nobody introduces ads or tracking. This is something I've learned to appreciate over the years.
On one hand, AI boosts Emacs development. On the other hand, as an Emacs user of 30 years, I have always felt that the number of people who deeply grasp Emacs Lisp and Emacs' internals is really small against the population of people merely using Emacs and lightly hacking their own setup, and I worry AI is not going to encourage any growth in that small elite that seems kinda important for Emacs' long-term future.
This is a good point, but I do want to mention that I feel like in the past 5 years we've had lots of extremely popular packages that hook into Emacs internals instead of rolling out their own architecture.
For example, corfu [0] versus company [1]. Company works with capf, but you can also write your own backends for it (specific to company). Corfu also works with capf, but all backends are capf functions instead of a corfu specific backend.
Another good example is eglot [2] versus lsp-mode [3]. Eglot is actually packaged with Emacs now.
There's also other stuff, like vertico [4] (and others that are recommended to download) versus helm/ivy.
I also want to mention that packages that hook into Emacs more don't necessarily mean that they're better. From my POV it's more like you get a lot more things for free and the documentation you dive into will be Emacs specific instead of package specific. It all comes down to preference.
Vertico/Counsel/Orderless is very nice, but Helm and Ivy are fully featured (I always forget how much Helm has for you).
I use corfu, eglot, and vertico now. I have thought about going back to helm and company, especially since I was very familiar with company's backends for a long time.
> AI is not going to encourage any growth in that small elite
In practice we're seeing the biggest waves of development in years. r/emacs gets daily, daily! announcements of new packages. Many of them, if not most, are not some AI-sloped trash - they are very useful. Some package makers go above and beyond - even though vibe-coded, they still show good design decisions, proper tests, hand-written documentation. Canvas stuff most likely wouldn't be possible without LLMs.
> the population of people merely using Emacs and lightly hacking their own setup
This is a good thing. Custom environments should be either minimal or upstream. Anybody should be able to sit down next to you and help you hack out a change. The more unusual/custom your environment is the less productive that is, and this more than balances out any possible gain you can make from custom setups. (don't forget to account for your cost to learn elisp and then make the changes!)
Somebody needs to make the correct setups. However most of us have better things to do.
I'm not advocating for making all (or even most) users spend so much time on internals that they don't get productivity gains. Rather, I'm concerned about maintaining, ensuring generational turnover, and healthily boosting the elite that the product depends on. It is no secret that a number of Emacs ecosystem core devs are middle-aged, and so the project is a few heart attacks or whatever away from losing the experience and competence that has sustained it so well.
Most of emacs is lisp. The actual C part is quite small considering the capabilities of the system. Lisp being what it is, it’s moslty about domain knowledge than language expertise.
I feel the lisp constructed on top needs significant language expertise. Lispy constructs of defvar, defconst, defcustom, alist, cl-loop etc. are quite extensively used in emacs - and need an understanding quite unique to Lisp. Of course, the domain then builds on top of this shared understanding of the contructs themselves.
I would say that loss of expertise in emacs-lisp is a significant loss, even if there continues to exist C-expertise globally.
It's just a Lisp dialect at the end of the day and not much more complicated to learn than Javascript. The only unusual aspect is its prevalent use of dynamic scoping, although nowadays lexical scoping is also available and encouraged AFAIK.
emacs 31+ started emiting this warning for my custom Lisp files:
Warning (files): Missing ‘lexical-binding’ cookie in "~/.emacs.d/custom.el".
You can add one with ‘M-x elisp-enable-lexical-binding RET’.
See ‘(elisp)Selecting Lisp Dialect’ and ‘(elisp)Converting to Lexical Binding’
for more information.
I am still trying to figure out what to do! The manual is quite verbose and I haven't had the patience to go through it yet.
It will add a cookie (lexical-binding) to the top of the file. If you want to do it manually put this:
;; -*- lexical-binding: nil; -*-
or this:
;; -*- lexical-binding: t; -*-
at the top of your custom.el file. They want it to be explicit now because eventually lexical will be the default. If you put in the former then when lexical becomes the default, the file will still use the current dynamic bindings. And if you use the latter, if there are issues you'll discover them now before the default changes and you're surprised by it.
There's a wealth of packages and the documentation for emacs-lisp is quite extensive. It's not some esoteric language. But what I'm talking about is that the code for the packages can be quite simple and readable.
>and I worry AI is not going to encourage any growth in that small elite
I wouldn't dismiss the help of lower friction of entry. Lots of recent Linux and neovim users due to how easy it is to debug an issue or edit a config now.
The larger the regular userbase, the more chances people gradually go deeper into the system.
It is is unreal how I can ask claude, from within emacs, to implement an extension for me on the fly, inject it into the running process, have it observe the results, and quickly iterate to a working solution.
I am also a member of the 30+ year emacs club (with a detour to jetbrains some years back due to java) and it has been crazy how good claude is at implementing/debugging emacs extensions, I have it set up so it has emacs in its container and it is able to basically use it headless to debug whatever.
Saying "I want my editor to do X" and have it happen basically realtime on an editor I fully control is incredible. I have written elisp in the past, but it's definitely one of my weakest languages, so being able to leverage claude to do this is great.
Any Lisp is good at editing live process, you just need to give it a REPL. Because of homoiconic nature of Lisp, every step in Read-Eval-Print-Loop differs. Lispers sometimes refer to Lisp REPL as the "true REPL", because non-homoiconic REPLs are rather "interactive shells" in comparison.
Clojurescripters for example can use nbb with the connected REPL and build web-scrapers while interactively "clicking" on buttons and exploring DOM directly from the editor.
In case of Emacs, it is not [just] an editor, technically it is a Lisp REPL loop with a built-in text editor. That's why you can virtually change any aspect of it on the fly, without ever having to restart it.
What's crazy that this allows to have pretty much anything "programmable". Even keyboard macros in Emacs are just series of Lisp instructions. You can compose a macro and then look at its underlying code, modify it and execute it.
Elisp is homoiconic and has a strong culture of REPL development, but really the thing that makes elisp so nice is that it has decades of use to iterate on an editor. There's an attempt to do this with Common Lisp that's quite cool, called Lem, but the sheer amount of person-years that have gone into making emacs and elisp a conjoined system makes it a pleasure to use and iterate on. Lem, in comparison, is building up all the UX associated with a "live programming environment" that just comes out of the box with elisp (though I, personally, prefer Common Lisp as a language/environment.)
Pre-LLM I used to spend the occasional afternoon at work when I was a bit demotivated just adding new features to my emacs or fixing small papercuts in the environment. Now I largely have the LLM work on it for me, though I separate out LLM code from my own by loading them separately in my config.
If you've read Pratchett's Discworld, I like to think of Emacs as an Igor: it's a loyal servant that can swap out its own parts, exchange them with other individuals, and rebuild itself on the fly.
But to answer your question, It's not just elisp itself, but rather that Emacs is basically a live elisp interpreter process with an editor UI on top, and the design is something of a ball-of-mud with few boundaries.
With typical systems you have plugins and they have fairly narrow interfaces. If you want to do something that's not covered by the plugin API, you're pretty much out of luck.
With Emacs, everything is open as a free-for-all to extend or redefine, so you can monkey-patch pretty much anything. Here's an example from my init.el:
(define-key global-map [remap move-beginning-of-line] 'move-beginning-of-line-dwim)
(defun move-beginning-of-line-dwim ()
"Cycles between the beginning of text on the line, the actual
beginning of the line, and the beginning of the body of a comment
on the line. If not in one of those three places, it starts at
the beginning of the text. Basically, it's a smarter HOME
command."
(interactive "^")
(comment-normalize-vars t)
(unless (and (bolp) (comment-search-forward (pos-eol) t))
(let ((cur (point)))
(beginning-of-line-text)
(if (= cur (point))
(beginning-of-line)))))
By default, the HOME key and Ctrl-a are bound to the `move-beginning-of-line` (defined in `simple.el`, one of the elisp source files that comprises vanilla Emacs). That `define-key` with the `remap` tells Emacs that everywhere in the global keymap that it sees the default `move-beginning-of-line`, it should replace it with my custom `move-beginning-of-line-dwim`.
Alternatively, I could have just done `(defun move-beginning-of-line ...)` and simply redefined `move-beginning-of-line` wholesale and it would probably have worked fine. But this is a little cleaner, IMO. Either way, now when I hit HOME key it cycles between column 0, the first non-whitespace character, and the first character in the body of a trailing comment.
On top of that, I don't need to have a formal plugin or anything. I can take the above code, paste it into an elisp buffer somewhere, put the cursor somewhere in or after the `(defun ...), hit Ctrl-x Ctrl-e and now that function is defined within Emacs (and callable by other functions). Same thing with the `(define-key ...)`: put the cursor on it, Ctrl-x Ctrl-e, and the binding is updated. No ceremony.
And for testing, I can edit the function freely, hit Ctrl-x Ctrl-e and now my edited version is the live one in the running Emacs process. It's a lot like a scripting language REPL except within the editor UI.
And in addition, Ctrl-h Ctrl-f tells you about any function that Emacs knows, defaulting to whatever function name the cursor is on. So if I put the cursor on `move-beginning-of-line-dwim` and hit Ctrl-h Ctrl-f RETURN, I get:
<home> runs the command move-beginning-of-line-dwim (found in global-map),
which is an interactive interpreted-function.
It is bound to C-a and <home>.
(move-beginning-of-line-dwim)
Cycles between the beginning of text on the line, the actual
beginning of the line, and the beginning of the body of a comment
on the line. If not in one of those three places, it starts at
the beginning of the text. Basically, it’s a smarter HOME
command.
[back]
Same thing for Ctrl-h Ctrl-v for variables and settings. The documentation that it shows is generated directly from the doc strings and live editor state. Ctrl-h Ctrl-k will prompt for a key and show me a key binding, so Ctrl-h Ctrl-k HOME will give me the above documentation now too. Ctrl-h Ctrl-b shows all applicable keybindings, etc.
Now I'd mentioned that you can monkey-patch anything. In practice that could cause chaos if you don't take care. A pretty common idiom in Emacs to do this more cooperatively are "hooks". These are just variables that some package, internal or external, defines to hold a list of functions to callback. The package iterates the list and calls them whenever the given event happens and you can add or remove your own function to the list to get that call. Think signals and slots, if you seen that design before. And these are pretty ubiquitous. As an example from my init.el:
So whenever syntax highlighting is started up in a buffer, it calls the font-lock-mode-hook callbacks, and that runs my code to register a regexp to highlight my initials and other fixme tags.
And if all that's not enough, Emacs also has an "advice" system which lets you register code to run before, after, around, etc., any existing function. (And then later unregister it if you wish.) There's also a built-in elisp debugger to break into a function and step through it.
So basically, the key I'd say is that there's no real privileged code in Emacs. You can redefine pretty much anything to taste, and do so without even having to reload Emacs. The downside is that it's up to you to decide what to trust. It's on you to avoid breaking it, and you probably want to be choosy about the packages you run.
Emacs is designed so only the most core operations are in C. Everything else is in ELisp, and can be manipulated to your heart's content while Emacs is running. It's pretty similar to Smalltalk VMs in that way; the only real difference is that one is functionally oriented and the other object oriented, but both are a dream to use.
There are a number of environments and languages that have the capability to reload things extensively at runtime. elisp is mostly nice because it is polished, but it isn't necessarily the "best". Erlang has a claim on being better at it, probably. And while most scripting languages are capable of it, that doesn't mean you can just drop one in and go necessarily. It helps to have an environment where that sort of interactivity is first-class and in constant use and testing, which is where the polish comes from.
Erlang the runtime sure. But Emacs is an application with these properties. There is no editor like Emacs for Erlang (some small clones I am sure) and no other user application utilizing this feature.
Smalltalk is a development environment and an applications platform. The development tools are as extensible and user customizable as Emacs. And like Erlang it is also a runtime you can package software for. Any GUI or server software. For Emacs you can probably do the same, but I’m not convince many users would find the GUI familiar.
you can replace or wrap arbitrary functions or update values freely in emacs. most of the editor is written in elisp. only the primitives are in c.
you can write (arbitrary (lisp)) and then just put the cursor after the end parenthesis and hit `Ctrl-x Ctrl-e` to evaluate it. It works just like you had typed out something in a python repl, only you can inspect, add, or update anything inside of your running copy of emacs.
As an example, I've had a chunk in my ~/.emacs for 15+ years that rewrites a few builtin functions to prefix all of the backup files emacs makes with a `.` because I don't like to see them in `ls` listings but still want them local to where they were made should I want to diff them against the current version. (the default is just a ~ suffix, and there's a common directory relocation many people use to pile them all in a backups directory somewhere)
As another, I wanted to be able to punch a button and drop the current datetime into a file, for files where I keep records and the like, so I added this:
Albeit, you needn't shell out to get a date in emacs, I dropped in in their years ago on a whim and just used what I knew at that time to toss it together.
well if you're in emacs you can C-x C-e evaluate whatever, and if you eval an edited version of whatever function emacs is calling, it just works as emacs calls the thing by symbol name; conceptually it's basically your editor is an elisp repl, so everything can be changed at any time (in general, things like defvar you'd need to setq and so on)
Some folks like having an MCP package. I agree that gives you a bit more control. But I live dangerously and run emacs in daemon mode and tell claude to just run emacsclient to execute elisp as needed. It works amazingly well. Claude has full visibility into my editor and together we can pretty much do anything.
In fact, I increasingly think of emacs as just a live lisp machine. It's a surface that I and the agents can interact against. It acts as a document store, database, control surface, etc.
I've been getting into emacs somewhat recently and really enjoying it so far, though I do worry a bit about how much it can do and whether it will lead to any sort of "oops, you opened a project that had a thing that autoexecs or exploits a parser and now you're pwned". I know that's not a unique problem to emacs, but it feels like the enormous amount of things emacs can do gives it a bigger attack surface for that (and I don't know my way around it well enough yet to be confident that I've looked at all the places that might happen)
Maybe the solution is that I should just be running the entire thing in a sandbox in any case.
I am too young to be in the 30 year club but Emacs has served me well for more than a decade. I don't use it as a daily driver anymore but it holds a special place in my heart.
Using magit made me believe again that really good software can exist and that there are really great designers still among us.
Also super agree that Stallman's original ideas are only ever more increasingly valid. I will generously say that Stallman has been an imperfect messenger but the core message has always been solid. I have not regretted my FSF membership over the years.
50 years old and feels more modern than any of the crap folks try to sell you "as the editor of the future". Emacs is the true editor of the past, present and distant future.
Modal editing was supposed to pull users away - Evil mode made vimming better. LSPs were supposed to kill it - only made it better. Electron-based crap was supposed to make terminal-native editors look ancient with a built-in terminal, extensions, and a polished UI. Emacs got vterm, eat, and ghostel. GitKraken-like GUIs were supposed to make the git CLI unnecessary. Magit is widely considered better than any git client that exists, GUI or not. Tree-sitter was supposed to require a "real" language server architecture to get accurate parsing. Emacs 29 absorbed it natively, and font-lock, indentation, and structural navigation across major modes got noticeably better. Obsidian and Notion keep trying to overcome it - Org-mode just keeps getting better. AI was supposed to make it outdated - only enhanced it.
For half a century, humanity has been searching for an Emacs-killer. All the while, Emacs has been a killer app all along.
I like it infinitely more than anything, but it also still feels like a comparably slow, crufty pos that will probably die because of how anti-AI half the core community is. Regardless of how good magit is, it's slow.
I also can't understand how people like eca and agent-shell so much unless they've never actually used any decent harness. Neither seems to really fit with emacs. Acp is the exact opposite of extensible, and eca isn't really extensible either.
The biggest value of gptel is its API. I can send a request anytime, anywhere, from pretty much any buffer. I sometimes ask things in the middle of typing a message, or I can ask a model to reword the prompt I'm about to send to another model.
Doesn't work with my github enterprise with entra sso integration. I left a question on github gptel but no progress as of yet. That drove me to agent-shell which requires a cli but works.
We just got lucky. Emacs Lisp, unlike most other Lisps that are data-oriented is particularly text-oriented. If instead of LLMs we've gotten LGMs (Large Graphics Models), Emacs wouldn't have time to catch up and keep the pace with other graphics-oriented IGEs (that would've replaced IDEs)
Luckily (for us), Emacs is the king of text-processing and text manipulation.
I will say in regards to the electron editors, wrangling emacs frames and windows can range from a chore to painful. That is one area we can still improve on!
I grokked display-buffer-alist and never had any problems since. With any other editor or IDE (and I used more than a few), it never occurred to me to even want to do anything complex with window placement. There are things I would love to see getting improved in Emacs, but managing windows and frames is not the one.
I think your perspective is perfectly valid, and I'd never advocate for dumbing down display-buffer-alist, but I do think some sort of package which makes common buffer configurations easy for novices who haven't put the effort in would make a big difference without getting in the way for those who've already grokked it
> some sort of package which makes common buffer configurations easy for novices
Experts often do forget their own "beginner's journey", but I honestly never remember struggling with where windows do appear in Emacs. Either because I never had any eccentric expectations of how this should work, or maybe because I had far bigger issues back in my beginnings. Maybe I didn't notice anything until I found Spacemacs, which had just started gaining some traction back then. I don't remember if they've done anything to improve beginner experience, but then, moving off Spacemacs I might have gotten annoyed, which iirc forced me to understand display-buffer-alist. And then trying Doom, I believe I had to explicitly disable all their novice-aimed improvements and rely on display-buffer-alist settings I was already comfortable with. So, I guess it's a difficult balancing game - need to make it intuitive for the beginners, while not screwing it up for the experts. I mean, if Emacs v32-33 ships with "improvements" that somehow mess with my display-buffer-alist, I'd probably get mad for like two minutes. But that's me, if anything like that to happen, I'm sure it will generate some 2000-message-long discussion thread on emacs.devel.
I programmed in Emacs in a myriad of different languages, I used it to write my thesis, to write my homework and later to grade them. I’ve used it to publish countless blog articles, wiki pages and technical documents.
I read that I was hired at my first job from en email received inside Emacs, I’ve used it to send countless emails to colleagues, employers and business partners. I planned both my personal and professional life inside it, I’ve used it to track the time spent doing a certain task when no such software was yet available.
Most of the time I’ve spent in front of a computer over the last 20 years, was inside Emacs. Happy Birthday, Emacs! You’re the best thing that happened in the computing world.
Is anybody here consciously trying to keep their Emacs configs/setup "lean", minimalist, as small as possible?
I'm not a coder, but I did use Emacs daily around 2010-2012, with brief returns later. I always gave up eventually because the complexity of addons, the org-mode-can-do-everything-so-I-should-do-everything-with-it etc just grew over my head. I've discovered that I like Plan9 Sam, Acme and, in general, the one-thing-well camp better. Each their own, I guess.
That said, I did often like how "immersive" using Emacs can actually be at times. I'm a trained journalist, and it made managing bits of information, including PDFs etc, really streamlined, almost like a wonder. And, I had my own little OS on a USB stick that way (though the minimalist in me always whined that "an editor" should not weigh 100+ megabytes).
Incredible that it has been around for 50 years, with no signs whatsoever of being a "paradigm of the past".
I've been using emacs for ~15 years. I don't now what is considered lean. My init is 343 lines. Probably removing all the comments and junk collected over the years it is likely ~200 that actually does anything useful at this point, I should probably clean up. I use emacs everyday. I get the desire to want to do everything in emacs but I also don't. It is good at what it does, it happens to do other things too but I don't know if that is the best way to work.
I've been using emacs for around 30 years and your comment made me curious. My .emacs is 237 lines. It used to be more, but I cleaned out the Java and Octave support I wasn't using anymore.
Kinda, I don't mind having quite a few packages but they are mostly self-contained in their use-package blocks. This way even if things go wrong it's usually just one package I gotta remove and not something that's intertwined with the whole config.
Using emacs for 4-5 years now and it's been a fantastic experience so far.
With my last bankruptcy where I tried to dissect my 12K LOC config to identify the bloat and the crap I no longer needed, I found very few pieces that weren't used. Turns out, my config was already modular and lean, in the sense that everything I had there had a practical reason to be in there.
Once I started using LLMs to deal with Emacs, I decided to add a bunch of tests to run them in CI, just to prevent regressions. My config since then has grown to 26K LOC + 35K of tests. I consume 250 third-party packages, plus about 100 built-in libs.
My Emacs starts and loads within a second. I have no problems such as freezing, breaking or leaking memory. With all this stuff I have in it, it can run for days and weeks and its memory usage on Mac stays within a comparable range with the Slack app - around 500MB.
I never understood this obsession with keeping Emacs lean. Bruh, throw some shit into it, let it burn, it'll chug on any large amount of Lisp and still give you the smoothest ride ever. What's the point of keeping a colossal beast under a mountain and feeding it a low-calorie diet? It's like digital abuse. Emacs these days is capable of rendering Doom-level graphics, it's offending to use it like notepad.exe.
I had a similar experience where I tried to declare bankruptcy after havning not used emacs for a year and a half or so, ended up re-implementing things until finally I was like 'no I was right the first time'.
That said, damn, my emacs config is like 1000 LOC and takes like 20 seconds to load. Also the reason I keep leaving Emacs is definitely the complexity of the bugs and the edge-of-the-edge case things that come up when I'm just trying to do something simple (the other day it crashed after running `e: newfile`, the evil mode command for editing a new file. I have no idea why it crashed but after it did the program couldn't be killed. Maybe it was because I was trying to open a file with no extension, but even that's a stretch.
Anyway would you mind if I sent you my config sometime or looked at yours? It's never occurred to me to write regression tests
Of course¹, but I warn you - it may feel massive, I do tons of (at first) seemingly weird stuff. Like OCRing images in my clipboard (which is now a separate package²)
I ran Emacs for ~25 years with almost no custom configuration. I could not be bothered, and the defaults were great
In the last decade I have started to add configuration. When GPT-3 became available, and I did not have to learn Elisp (another f%^&*n computer language - with no other use) I have extensively configured my Emacs
> though the minimalist in me always whined that "an editor" should not weigh 100+ megabytes
Heh. At work many in our department installed a (voluntary) tool that logs the apps we have in memory, and how much RAM they consume.[1]
My manager came to me and said "Your Emacs is taking 8GB of RAM?!"
Guess we should call it EGACS now.[2]
I had an LLM do some debug and it turned out my copy of Emacs is a bit buggy in MacOS. Every time I open a new frame, and then close it, it doesn't release a lot of GUI related stuff. Over several weeks, this leak adds up. I open new frames multiple times a day.
And of course, I got the LLM to make a package I can load in Emacs that cleans it all up without needing to quit.
After cleanup, it's taking "only" 1.5 GB of RAM.
[1] Company is dramatically reducing the amount of RAM on new laptops, so we want to gather data to show it's too little RAM.
[2] For those who don't get it, a common joke decades ago was that Emacs stood for Eight Megabytes and Constantly Swapping. Back when 8MB RAM was huge.
> Is anybody here consciously trying to keep their Emacs configs/setup "lean", minimalist, as small as possible?
I tried but most of my config is just variable settings (with the use-package macro). I don’t really have custom code there. If I do think about a feature, I tried to build a package instead (like one for bridging subsonic and emms).
After a couple of years of detour I’m back to using Emacs since all the fancy lsp, debugger etc stuff in VSCode and Zed doesn’t matter as much for me anymore and I am just more productive with Emacs. But I am still using it like it is 2020. I hear people using coding agents to make crazy customizations to their emacs config and I can imagine Emacs is particularly suitable for this.
Curious what are the biggest things that have come out in the last year or two, and what emacs based personal software have others reading this made?
Wow I missed canvas support completely. This is going to make some custom UI's way easier to make compared to the hacks I had to resort to in the past [0]
I do hope one day we'd get a new cross platform performant display engine that draws like Zed does for more UI capabilities in Emacs. Neomacs[1] promises this and has some of this but looks like its suffering from never ending scope creep and continuously moving back and forth between 80% there and 90% there due to unattended agents running wild.
It looks like exc.el is built on top of a reactive UI framework, which, well, would have been incomprehensible to the first users of GNU Emacs on PDP-11 UNIX…
Just ask Claude or whatever to hook up gptel and eca (or agent-shell). You don't even need to read anything, just literally talk to the LLM. The first step is to get to the point where agents can change Emacs from the inside out - and then, that opens the floodgates for any ideas.
Just yesterday I decided to make it possible to detach a video I'm watching (and of course controlling directly from Emacs) from my browser. The active YT video stops playing in the browser, loads mpv, and seamlessly continues, while keeping the time, speed, and volume. It's now possible with the new Canvas API to play videos directly in Emacs; at some point I may try to figure that out. Why? Well, just because I can. With Emacs, the limit is your imagination and nothing else.
Craziest thing? I never had to restart, recompile, rebuild anything. I was watching a video, thought: "hmm, a floating window would be nice..."; without missing a beat, just typed the prompt and made that happen within minutes.
not big but i'm still happy about how it allowed me to build a really expressive musical tracker with micro-tonality implemented by default. partly by Csound score paradigm but we also have an interesting macros, a scale paradigm for adding notes and real-time p-field information
About two or three months ago I ditched Neovim as all the complicated modern crap wasn't working for me, and instead of reverting to Vim, I switched to Emacs and Doom + eVil, and am relieved to be back in a nice stable system again. I did ask GPT to port over my key commands and shortcuts, which it did, and things are great again!
The extension language should be a full featured programming language in its own right capable of creating substantial applications because that is something people will want to do!
I wish every application worth putting a plugin system in it followed this philosophy.
> I wish every application worth putting a plugin system in it followed this philosophy.
Does it open the door for compromising on the core XP whilst expecting everything to be a plugin for example? It's also making the task of testing N^2 complex.
Sometimes a well-thought-through plugin system is no plugin system.
Kakoune (https://github.com/mawww/kakoune) is a good example of it.
I know it's an Emacs celebration party, but that one decision made Kakoune super
stable and nice to use.
(I'm looking at you NeoVim).
>Does it open the door for compromising on the core XP
in some applications yes, in Emacs I'd say no because Emacs itself is extensible and let's people utilize its own core functions and is itself almost like a mini OS. For example the completion framework is enhanced rather than replaced by plugins like Consult.
There's a systems thinking aspect to Emacs plugin development. People make plugins always with Emacs itself in mind and to improve Emacs rather than merely the plugin. It's very anti-Unix philosophy in that way. Org-mode or Magit are good examples of this, they work well, and really only well, within Emacs.
It's what I've struggled with every time I tried out NeoVim where I ended up with ten plugins all loosely held together by tape and always something broke when something else was updated.
What a deeply strange article. It starts out deep in the details of Emacs' origins, then suddenly gives up, fast forwards and ends with a whimper.
ps. My first sight of the author was in a basement lab at the Weizmann Institute in 1986, sitting cross-legged on a chair working in front of the then-wondrous brand new Sun workstations - the so-called "3M standard" (1MB of RAM, 1MHz CPU, 1M pixels). Good times but old times!
Finally, because of the LLMs, i'm in Emacs Religion. I traed it before many many times, being defeated always by a config file, by a module not working, etc. But with WSL, Claude and Doom Emacs, problem is solved.
I realidad that integraron it with tmux and claude cli, it is un unbeatable program.
About 10+ years ago I found a guide on Helm [0] and a guide on Org-mode [1] when I was just getting into Emacs. This helped me move on from using Spacemacs to making my own configuration.
I no longer use Helm (I'm doing Vertico/Orderless/Consult), but I've stuck with Org-mode since then. I sometimes venture out to other apps (like Joplin, Obsidian, Apple Notes, Apple Reminders, etc), but Org-mode just works best for me.
I don't even use it's most advanced features. The most complicated thing I do is maybe recurring schedules and using the agenda. I don't even have agenda view defined (although I really should at this point, it would be really helpful).
I use it every day at work with a daily log.org file keeping track of what I did each day, a habits.org file for recurring tasks I want to make sure I do (check my email, find a PR to review, etc).
I have various files to help organize my personal life - I heavily rely on Beorg [2] for that.
Looking back on my years with Org-mode, I feel like the primary reason I use it is for the ease of use with keybindings and dealing with plain text. I don't need to dig through menus or swipe around. I just go in and type, write, and delete.
emacs is really something apart, by far the best software I ever had the chance to interact with, the closest thing we ever got of a lisp machine, a completly hackable, self documenting programming environment where you can change anything without limits.
It's unfortunate its underlying ideas aren't more widely used in our industry, the very idea that you don't need to expose a separate API for people to create and extends things since code is the api is a idea that put emacs on a league of its own .... Thank you to anyone who has been involved in developing it.
Also I would love to hear Stallman view of labs using (A)GPL code and not contributing back to the world since this is completly against not only the ethos of free software but what Stallman teached to the world about the very purpose of its license
A coworker of mine launched a Windows port (clone?) of emacs when he came in for the day, and never left it for the entire workday --- always envied him his facility with that, but never quite got comfortable with it (and even in a fit of pique gave away a printed copy of the LISP manual which I kind of regret now).
The ironic thing is I've been fascinated by similar graphical efforts such as the Glamorous Toolkit.
I have yet to find a reason to switch away from emacs as my primary work flow editor. I've been using it for at least 30 years now.
Why do I prefer it to (say) Turbo Pascal or Borland C++? Both of whom "Visual Studio" style environments have inherited a lot from? Well, those two worked well when one didn't have multiple consoles or terminals, and on a single tasking OS (DOS).
I do not want or need my editor to be my whole UI. (I know Emacs can do it, it's just not something I either want or need). And I am not comfortable with a UI that demands changes from Emacs in order to function, as any such UI suffers from blocking effective development, especially for (say) embedded code spaces.
Can there be better than Emacs? Yeah, probably. It's certainly not the most intuitive interface, for instance.
My biggest regret in life was that I was introduced to vim before emacs and got really comfortable with it.
Did not realize that everything I was building in my vim configs to make it better was already default in emacs i.e dired, compile mode, magit, org mode, etc.
If I wasn't able to multiplex with tmux I would have switched to emacs a long time ago.
I love emacs and have been using it daily for about 5 years now.
Many people have mentioned magit and org mode. I just want to give another shout out to consult.el which is a wonderful way to grep and search through text.
I was very fortunate: Yale CS already used emacs in 1981, and offered local high school students the chance to take their classes. By the time I got to MIT a year later, I didn't know that there were any other serious editors available!
I got a nice case of emacs pinky back in my early 30's. Had to take disability, get physical therapy to rehabilitate, etc. Been vi all the way since then.
Been using an Org file containing all my projects as the tracker for each, with a little custom tool that wraps emacsclient as the driver which my agents use. It's been pretty great, but the single-thread bites as it can get wedged sometimes and then I have to go hit C-g.
I quit being an emacs tourist about 5 years ago, this year I started rewriting my init.el with use-package and the popular packages (vertico, eglot, etc). My config is still a mess and there’s always something new I want to do. Sometimes I think about trying neovim or trying some editor that I wouldn’t have to config stuff that much, but I think I’d want to customize things a certain anyway.
For LLM stuff I’ve been using eca, or claude code in a vterm or ghostel. I’m still experimenting with this stuff but I don’t think emacs is getting in my way. Not sure if I’d recommend to everyone, though.
I was lucky enough to have access to TOPS-20 at WPI in 1986 - 1988 (The DEC-20 was replaced with an Encore Multimax running UNIX as the student mainframe). TOPS-20 had a bunch of editors, I tried them all. I remember TVI, TECO and EDT, but I'm sure there were more. I already had experience with WordStar (C and assembly language programming on a PC) and various line editors, so although I used it, I never became an Emacs fanatic.
The most important software missing from the new Encore UNIX (Umax) was MM- the TOPS-20 integrated mail and bulletin board program. A friend of mine wrote "bboard" a campus messaging system as a replacement (this was soon replaced with USENET). It had a bad integrated editor, so I wrote my own editor as its replacement, this became the editor JOE. Even so, Emacs was always there as the counter-example. In those days, Emacs was large and slow and had a limited file size, and it was easy to do better if you weren't focused on extensibility.
I don't remember "not running", but I certainly do remember those annoying "garbage collecting... done." messages in C Emacs. The eventual solution from the mid 90s was kind of awesome: improve the garbage collector? No: Just stop showing the message.
I remember getting a DOS port of Gosling Emacs on floppy disk at a computer show (there was always somebody selling "shareware" at those). I lost that disk, and for a long time had no access to the Gosmacs source code, but eventually someone sent it to me. Sadly, we can not share it- James Gosling closed it. Some other Emacsen: MicroEmacs, Epsilon, JOVE and JED.
Good times of ISPF on IBM 3090/TSO. First you had to allocate a file on a dataset (ibm hates simplicity) and then you edited the text or copied with the pair "cc/mm" followed by a/b. No keyboard shortcuts, no interactive shell, only a data-entry panel and the incessant "tlac tlac" sound of the 3270 keyboard
I started using Emacs 30 years ago. Used it as my main code editor for 15 years, and as my note-taking editor a little longer. I did write my share of elisp code, had a lot of fun with it, posted on gnu.emacs.sources back in the day, and shared a lot.
Emacs is still my main editor over ssh, so I happen to use it on a regular basis, and the commands are all imprinted on my fingers' muscle memory, so that's quite the comfort zone.
Emacs is awesome, but it is unfortunate that on Windows it still only supports x64, which is a legacy platform at this point. Hopefully arm64 will be supported soon as well!
Emacs is a serious tool, you choose it first and only then prioritize on the OS. It's like complaining that editing videos with Adobe Premiere on Linux is not a very solid experience, or something like that. Well, if you're a pro video-editor and you must use Premiere, then maybe you need a non-Linux box to do that?
It's almost not even funny, but I tangle all my dotfiles from an org-mode file. The files it generates are all read-only - to discourage me from writing in them directly. This makes my OS config semi-immutable. Bootstrapping a system from scratch takes no longer than a few minutes and the biggest bottleneck is properly getting access to that dotfiles.org and installing Emacs. This has worked for years and that's why I never had to really learn Nix. I guess Emacs for me is the "true OS", and whatever on top is "just kernel stuff"
If you're feeling curious at trying Emacs out for the first time (or just want to see what's new in the past decade or so), may I humbly suggest you take a look at my starter config: https://codeberg.org/ashton314/emacs-bedrock
When I first started using Emacs, my dad gave me his config. (Yes, I actually experienced https://xkcd.com/297/ irl.) A few years ago a friend of mine asked for some help getting a simpler Emacs setup—they wanted to move off of Doom Emacs. I made Bedrock as a bare-bones starting point that focuses on built-in customization and understandability. Even if you're comfortable in your own setup, you might find something useful in the files there. :)
So here's an embarassing confession for the occasion:
I code in Emacs almost every day. I read and write e-mail in Emacs almost every day. I take notes in Emacs almost every day. I maninpulate data in Emacs almost every day. Yet I don't know LISP (any LISP!) at all, I barely use any packages beyond "whatever it is that Debian ships by default", and I'm quite bad at fancy Emacs shortcuts. My Emacs config file is a hodge-podge of little snippets I don't properly understand – and it measures in at just about 100 lines, including comments and whitespace, with a significant part of that being just mundane configuration data for the mu4e Emacs client!
This has been the case for about 15 years now. And I'm the kind of person who really likes to know my tools. It's such a ridiculous situation! I somehow never get properly around to sitting down and learning, and I really struggle to make LISP click.
Sigh. I hope I'm not alone. I really really really should learn this thing!
Anyway, the most important part is: Despite all of this, Emacs is still fantastic for me! Here's to the next 50!
I'm a Lisper. I switch between Lisp dialects, sometimes multiple times a day. Since I got my LLM harness to work from inside of Emacs I no longer need to even look at Lisp that it generates for my config.
It is very justified use of AI - if anything breaks, it breaks for me, and mostly just for me. And whenever something doesn't work as expected - I don't even try to debug it anymore - my harness has introspective capabilities - it can run the profiler, monitor changing vars, debug and just fix things.
Now is the best time to try Emacs. If people before could complain that Lisp is weird and not easy to grok, it's not a valid complaint anymore.
Been using Emacs for 37 years. Didn't start learning Elisp until 6 years ago. It's never too late. Wrote an Elisp Cheatsheet for Python Programmers, which helped me level up. Perhaps this might as helpful to you.
I find it interesting actually. Not embarrassing. You mastered the feature layer more than I. I went into lisp with dreams of making my own features but turns out I was quite limited.
You're doing it right. When I was gainfully employed, emacs was purely a black-box means to a greater end, i.e., promotions and added responsibility. In my premature retirement, the vortex of emacs became an end unto itself. Believe me, I'd happily trade my emacs expertise for a more meaningful pursuit.
I've been using emacs everyday for the last 25ish years. Although I do read elisp and occasionally write some, I'm far from fluent. You do not need to know lisp to use emacs (although it is funny you didn't pickup some just by osmosis).
We have finite time in our lives. I'd argue it's eminently reasonable to spend time on things other that Emacs' guts, unless that's what tickles your interest.
I've always told people: You can be a power Emacs user without learning elisp.
I myself used Emacs heavily for 9 years before learning elisp (clicked on my 3rd attempt).
IMO, the included Elisp guide is not good for beginners. My recommendation:
Separate the language from the ecosystem. First focus on simply learning the basics. How do you set a variable? How do you write a loop? How do you write a function? These things are as easy in Elisp as they are in other languages. Perhaps use Exercism to practice.
Of course, also learn the related keybindings (C-M-x to evaluate, C-x C-e, etc).
Only then start understanding some of the basics of integrating with the rest of Emacs (unwind-protect, save-excursion, save-restriction, etc).
I lived in Emacs for most of my professional live, but IDEs and now Claude have taken over. Sad, but perhaps justified? Back in my academia days, there was much less pressure to use a uniform tech setup across staff, so people were happily using Emacs, or vim, or whatever -- and frankly, there was never any issue because of that.
But I can see there is a value (mostly for the admins, but also for debugging if you work collaboratively in a team) in enforcing the same setup for everyone. Sigh. Strangely, I could never convince my coworkers to ditch their IDEs for Emacs.
100% completely opposite experience. Emacs is hands down the king of any kind of text-manipulation. And not only on the composition side. Most editors and IDEs are focused on the composition side of things - making text, adjusting text, amending text. And code btw, is nothing but structured text.
Emacs opens gates for text consumption - I'm reading this entire HN thread in Emacs, just like I consume Jira, Slack, Telegram, Reddit; control YT vids, my browser tabs and history, etc. I search through Splunk and Datadog logs, Wiktionary entries and just general googling - all done in Emacs. I browse million-line codebases on GH without ever having to clone them. If there's a piece of any kind of text in the computational vicinity to my active Emacs instance - this laptop and all connectable devices, I can easily make use of it.
And this gets incredibly important in the age of LLMs. I can read, manipulate, navigate, search through, diff, sort, group, slice, dice, salt and pepper any kind of text. Give me just about any other editor instead and I immediately will feel handicapped.
IDEs that are not malleable (by design) are at an exact disadvantage. I can change any aspect of my editor in the middle of typing this very comment without ever losing the state, the context, or my mental focus. No IDE even hypothetically capable of doing any of that.
Don't get me wrong, I totally agree with you re: text manipulation. That's exactly why I find it so frustrating that it's basically frowned upon in my current job. I do use it still, but must do so pretty much secretly at work.
At home, it's a different story.
I believe, Emacs is considered unprofessional in a lot of places?!
Emacs is considered unprofessional in unprofessional work places.
Dictating specific tools without a very strong technical justification is a strong signal that your management doesn’t trust you to make any important decisions.
The only expression I have gotten was something like "Why not vim?" and my response was "Because emacs is better, and I can always use evil-mode if I want the vim bindings". Then it gets installed (by me or an admin) and I use it. I can't imagine anyone actually caring, that's pretty petty of them, or lazy based on your other comment about it being too much work for sysadmins.
> Emacs is considered unprofessional in a lot of places
What? Why? Who the hell would ever forbid anyone from using a tool that literally makes them more productive? I mean, as the Russians say: "If drinking vodka at work interferes with your job, quit drinking vodka... at that job"
The main argument is that having the same setup on all work stations makes maintenance easier for the sysadmins and you don't run into inconsistencies between developers that only come about as a result of different setups.
It absolutely is. Consider this. I'm reading this thread in Emacs. Why? Am I obsessed with it? What's the point? Well, I can easily read not just the thread but also the article posted while ignoring all the fluff - graphics, banners, ads, etc. - to extract a piece of plain text.
I can also just ignore every conversation - sometimes, posted urls are more valuable than what people blabber and fight about. Imagine having to extract all the urls on the page. Some might say: "Hey, there's a browser extension for that", but...
a) the extension has its own keybindings, dissimilar UI, etc.
b) it won't ignore HN's internal URLs, so you still need to grab the list of URLs and then remove the ones you don't need in... your editor. So why not just use that, to begin with?
In Elisp, it's a one-liner. You can bind it to a key. I can also utilize sparse tree search, e.g., to collapse everything while leaving every reply that contains a keyword. With imenu, I can jump to any thread. With indirect buffers, I can compare two parts sitting on opposite ends of the discussion. I can narrow to any point, add some text, and then send a request to an LLM.
And guess what? All these things are still the same for a Reddit discussion. So when I use it in Emacs, I can still use the same ways of manipulating and extracting value.
one day, one of my teachers convinced me to try Emacs, and I’ve been using it ever since. At first, Emacs looked repulsive, but once you fall down the rabbit hole, you become addicted.
The reason Emacs survived 50 years while countless modern IDEs rose and died is architectural: Emacs isn't just a text editor with a plugin API—it's an interactive Lisp runtime that treats text buffers as first-class citizens.
Modern editors build layers upon layers of IPC, JSON-RPC protocols, and sandboxed extensions to keep the user from touching the core. Emacs did the opposite: it gave the user direct access to the live execution state. You don’t "configure" Emacs from the outside; you mold it into the exact operational extension of your own thought process.
In an era where modern developer tools consume gigabytes of memory just to render a UI tree, there is something deeply grounding about a piece of software from 1976 that still offers the most malleable computing medium on earth.
GNU Emacs really didn't start until 1984, but I keep thinking it would be interesting to compare Emacs' resource usage to Zed (or Gram). Then I realize I can't be bothered to run either of those long enough to do it.
Compared to VSCode, Eight Meg And Constantly Swapping does sound ridiculously parsimonious in 2026.
> it would be interesting to compare Emacs' resource usage to Zed (or Gram)
The core of GNU Emacs is written in C, and there are GNU-licensed Emacs variants which are entirely written in C. I really doubt anything like a new Zed/Gram fork would perform better than, say, QEmacs.
The so called editor wars seem to be over and emacs has lost. I've been involved with it since the early 2000s and it's still my primary editor. I feel that the users have reduced into a smaller but more dedicated/passionate group which is probably for the best.
You apparently missed the explosion in Emacs activity in the 2010s. I, too, remember using Emacs in the early millennium and feeling like a partisan of one powerful but nevertheless unpopular editor, with an uncertain future. But once the Mastering Emacs blog, Org-Mode, and Sacha Chua came along, suddenly there were so many new packages to install and tips for one's own config, and things like the pure-gtk build brought UI improvements going beyond merely look and feel.
In the early millennium, I as a Emacs user had hardly anyone to actually talk about Emacs with, even on nerd hangouts like Slashdot or the dedicated Freenode channel. Since the 2010s, one can make oneself practically a whole social life around Emacs.
I have been using Emacs for more than 30 years now. Other editors have come and gone, Emacs stayed. Parts of my configuration are more than 30 years old.
There were better and worse times in Emacs history. Recent times, however, are really good. Emacs is maintained and developed actively and there are many external packages which are impressive. Magit and ghostel are good examples of packages that I use on a daily basis to get my work done.
Recently, AI completely changed how I use Emacs, and in a very good way. I now treat AI as a fairy that can fulfill any wish. I describe how I want my editor to work, and boom! it works that way.
Examples: window and tab management, difftastic integration, markdown previews with beautifully rendered tables, markdown previews as PDFs, and many more.
What is most important, however, goes back to Stallman's original ideas. I am in control of my editor and my environment. I decide how it will look and behave. No corporation decides for me. No corporation builds in a new AI assistant. Nobody introduces ads or tracking. This is something I've learned to appreciate over the years.
On one hand, AI boosts Emacs development. On the other hand, as an Emacs user of 30 years, I have always felt that the number of people who deeply grasp Emacs Lisp and Emacs' internals is really small against the population of people merely using Emacs and lightly hacking their own setup, and I worry AI is not going to encourage any growth in that small elite that seems kinda important for Emacs' long-term future.
This is a good point, but I do want to mention that I feel like in the past 5 years we've had lots of extremely popular packages that hook into Emacs internals instead of rolling out their own architecture.
For example, corfu [0] versus company [1]. Company works with capf, but you can also write your own backends for it (specific to company). Corfu also works with capf, but all backends are capf functions instead of a corfu specific backend.
Another good example is eglot [2] versus lsp-mode [3]. Eglot is actually packaged with Emacs now.
There's also other stuff, like vertico [4] (and others that are recommended to download) versus helm/ivy.
I also want to mention that packages that hook into Emacs more don't necessarily mean that they're better. From my POV it's more like you get a lot more things for free and the documentation you dive into will be Emacs specific instead of package specific. It all comes down to preference.
Vertico/Counsel/Orderless is very nice, but Helm and Ivy are fully featured (I always forget how much Helm has for you).
I use corfu, eglot, and vertico now. I have thought about going back to helm and company, especially since I was very familiar with company's backends for a long time.
[0]: https://github.com/minad/corfu
[1]: https://github.com/company-mode/company-mode
[2]: https://github.com/joaotavora/eglot
[3]: https://github.com/emacs-lsp/lsp-mode
[4]: https://github.com/minad/vertico
I was using Helm, lsp-mode, yasnippet, and the like for a long time. I switched to Eglot/Corfu/Vertico/Tempel. I much prefer the new wave.
> AI is not going to encourage any growth in that small elite
In practice we're seeing the biggest waves of development in years. r/emacs gets daily, daily! announcements of new packages. Many of them, if not most, are not some AI-sloped trash - they are very useful. Some package makers go above and beyond - even though vibe-coded, they still show good design decisions, proper tests, hand-written documentation. Canvas stuff most likely wouldn't be possible without LLMs.
> the population of people merely using Emacs and lightly hacking their own setup
This is a good thing. Custom environments should be either minimal or upstream. Anybody should be able to sit down next to you and help you hack out a change. The more unusual/custom your environment is the less productive that is, and this more than balances out any possible gain you can make from custom setups. (don't forget to account for your cost to learn elisp and then make the changes!)
Somebody needs to make the correct setups. However most of us have better things to do.
I'm not advocating for making all (or even most) users spend so much time on internals that they don't get productivity gains. Rather, I'm concerned about maintaining, ensuring generational turnover, and healthily boosting the elite that the product depends on. It is no secret that a number of Emacs ecosystem core devs are middle-aged, and so the project is a few heart attacks or whatever away from losing the experience and competence that has sustained it so well.
Most of emacs is lisp. The actual C part is quite small considering the capabilities of the system. Lisp being what it is, it’s moslty about domain knowledge than language expertise.
I feel the lisp constructed on top needs significant language expertise. Lispy constructs of defvar, defconst, defcustom, alist, cl-loop etc. are quite extensively used in emacs - and need an understanding quite unique to Lisp. Of course, the domain then builds on top of this shared understanding of the contructs themselves.
I would say that loss of expertise in emacs-lisp is a significant loss, even if there continues to exist C-expertise globally.
It's just a Lisp dialect at the end of the day and not much more complicated to learn than Javascript. The only unusual aspect is its prevalent use of dynamic scoping, although nowadays lexical scoping is also available and encouraged AFAIK.
emacs 31+ started emiting this warning for my custom Lisp files:
Warning (files): Missing ‘lexical-binding’ cookie in "~/.emacs.d/custom.el". You can add one with ‘M-x elisp-enable-lexical-binding RET’. See ‘(elisp)Selecting Lisp Dialect’ and ‘(elisp)Converting to Lexical Binding’ for more information.
I am still trying to figure out what to do! The manual is quite verbose and I haven't had the patience to go through it yet.
If you open the file and execute:
It will add a cookie (lexical-binding) to the top of the file. If you want to do it manually put this: or this: at the top of your custom.el file. They want it to be explicit now because eventually lexical will be the default. If you put in the former then when lexical becomes the default, the file will still use the current dynamic bindings. And if you use the latter, if there are issues you'll discover them now before the default changes and you're surprised by it.There's a wealth of packages and the documentation for emacs-lisp is quite extensive. It's not some esoteric language. But what I'm talking about is that the code for the packages can be quite simple and readable.
>and I worry AI is not going to encourage any growth in that small elite
I wouldn't dismiss the help of lower friction of entry. Lots of recent Linux and neovim users due to how easy it is to debug an issue or edit a config now.
The larger the regular userbase, the more chances people gradually go deeper into the system.
I think that is part of the beauty of Emacs -- it is what one makes of it.
It is is unreal how I can ask claude, from within emacs, to implement an extension for me on the fly, inject it into the running process, have it observe the results, and quickly iterate to a working solution.
Claude, the ultimate REPL.
I am also a member of the 30+ year emacs club (with a detour to jetbrains some years back due to java) and it has been crazy how good claude is at implementing/debugging emacs extensions, I have it set up so it has emacs in its container and it is able to basically use it headless to debug whatever.
Saying "I want my editor to do X" and have it happen basically realtime on an editor I fully control is incredible. I have written elisp in the past, but it's definitely one of my weakest languages, so being able to leverage claude to do this is great.
Curious, is elisp particularly good at that (editing a process while it's running)? I've never experienced a system like that before, so I'm curious.
Any Lisp is good at editing live process, you just need to give it a REPL. Because of homoiconic nature of Lisp, every step in Read-Eval-Print-Loop differs. Lispers sometimes refer to Lisp REPL as the "true REPL", because non-homoiconic REPLs are rather "interactive shells" in comparison.
Clojurescripters for example can use nbb with the connected REPL and build web-scrapers while interactively "clicking" on buttons and exploring DOM directly from the editor.
In case of Emacs, it is not [just] an editor, technically it is a Lisp REPL loop with a built-in text editor. That's why you can virtually change any aspect of it on the fly, without ever having to restart it.
What's crazy that this allows to have pretty much anything "programmable". Even keyboard macros in Emacs are just series of Lisp instructions. You can compose a macro and then look at its underlying code, modify it and execute it.
Elisp is homoiconic and has a strong culture of REPL development, but really the thing that makes elisp so nice is that it has decades of use to iterate on an editor. There's an attempt to do this with Common Lisp that's quite cool, called Lem, but the sheer amount of person-years that have gone into making emacs and elisp a conjoined system makes it a pleasure to use and iterate on. Lem, in comparison, is building up all the UX associated with a "live programming environment" that just comes out of the box with elisp (though I, personally, prefer Common Lisp as a language/environment.)
Pre-LLM I used to spend the occasional afternoon at work when I was a bit demotivated just adding new features to my emacs or fixing small papercuts in the environment. Now I largely have the LLM work on it for me, though I separate out LLM code from my own by loading them separately in my config.
If you've read Pratchett's Discworld, I like to think of Emacs as an Igor: it's a loyal servant that can swap out its own parts, exchange them with other individuals, and rebuild itself on the fly.
But to answer your question, It's not just elisp itself, but rather that Emacs is basically a live elisp interpreter process with an editor UI on top, and the design is something of a ball-of-mud with few boundaries.
With typical systems you have plugins and they have fairly narrow interfaces. If you want to do something that's not covered by the plugin API, you're pretty much out of luck.
With Emacs, everything is open as a free-for-all to extend or redefine, so you can monkey-patch pretty much anything. Here's an example from my init.el:
By default, the HOME key and Ctrl-a are bound to the `move-beginning-of-line` (defined in `simple.el`, one of the elisp source files that comprises vanilla Emacs). That `define-key` with the `remap` tells Emacs that everywhere in the global keymap that it sees the default `move-beginning-of-line`, it should replace it with my custom `move-beginning-of-line-dwim`.Alternatively, I could have just done `(defun move-beginning-of-line ...)` and simply redefined `move-beginning-of-line` wholesale and it would probably have worked fine. But this is a little cleaner, IMO. Either way, now when I hit HOME key it cycles between column 0, the first non-whitespace character, and the first character in the body of a trailing comment.
On top of that, I don't need to have a formal plugin or anything. I can take the above code, paste it into an elisp buffer somewhere, put the cursor somewhere in or after the `(defun ...), hit Ctrl-x Ctrl-e and now that function is defined within Emacs (and callable by other functions). Same thing with the `(define-key ...)`: put the cursor on it, Ctrl-x Ctrl-e, and the binding is updated. No ceremony.
And for testing, I can edit the function freely, hit Ctrl-x Ctrl-e and now my edited version is the live one in the running Emacs process. It's a lot like a scripting language REPL except within the editor UI.
And in addition, Ctrl-h Ctrl-f tells you about any function that Emacs knows, defaulting to whatever function name the cursor is on. So if I put the cursor on `move-beginning-of-line-dwim` and hit Ctrl-h Ctrl-f RETURN, I get:
Same thing for Ctrl-h Ctrl-v for variables and settings. The documentation that it shows is generated directly from the doc strings and live editor state. Ctrl-h Ctrl-k will prompt for a key and show me a key binding, so Ctrl-h Ctrl-k HOME will give me the above documentation now too. Ctrl-h Ctrl-b shows all applicable keybindings, etc.Now I'd mentioned that you can monkey-patch anything. In practice that could cause chaos if you don't take care. A pretty common idiom in Emacs to do this more cooperatively are "hooks". These are just variables that some package, internal or external, defines to hold a list of functions to callback. The package iterates the list and calls them whenever the given event happens and you can add or remove your own function to the list to get that call. Think signals and slots, if you seen that design before. And these are pretty ubiquitous. As an example from my init.el:
So whenever syntax highlighting is started up in a buffer, it calls the font-lock-mode-hook callbacks, and that runs my code to register a regexp to highlight my initials and other fixme tags.And if all that's not enough, Emacs also has an "advice" system which lets you register code to run before, after, around, etc., any existing function. (And then later unregister it if you wish.) There's also a built-in elisp debugger to break into a function and step through it.
So basically, the key I'd say is that there's no real privileged code in Emacs. You can redefine pretty much anything to taste, and do so without even having to reload Emacs. The downside is that it's up to you to decide what to trust. It's on you to avoid breaking it, and you probably want to be choosy about the packages you run.
Emacs is designed so only the most core operations are in C. Everything else is in ELisp, and can be manipulated to your heart's content while Emacs is running. It's pretty similar to Smalltalk VMs in that way; the only real difference is that one is functionally oriented and the other object oriented, but both are a dream to use.
There are a number of environments and languages that have the capability to reload things extensively at runtime. elisp is mostly nice because it is polished, but it isn't necessarily the "best". Erlang has a claim on being better at it, probably. And while most scripting languages are capable of it, that doesn't mean you can just drop one in and go necessarily. It helps to have an environment where that sort of interactivity is first-class and in constant use and testing, which is where the polish comes from.
Erlang the runtime sure. But Emacs is an application with these properties. There is no editor like Emacs for Erlang (some small clones I am sure) and no other user application utilizing this feature.
Smalltalk is a development environment and an applications platform. The development tools are as extensible and user customizable as Emacs. And like Erlang it is also a runtime you can package software for. Any GUI or server software. For Emacs you can probably do the same, but I’m not convince many users would find the GUI familiar.
you can replace or wrap arbitrary functions or update values freely in emacs. most of the editor is written in elisp. only the primitives are in c.
you can write (arbitrary (lisp)) and then just put the cursor after the end parenthesis and hit `Ctrl-x Ctrl-e` to evaluate it. It works just like you had typed out something in a python repl, only you can inspect, add, or update anything inside of your running copy of emacs.
As an example, I've had a chunk in my ~/.emacs for 15+ years that rewrites a few builtin functions to prefix all of the backup files emacs makes with a `.` because I don't like to see them in `ls` listings but still want them local to where they were made should I want to diff them against the current version. (the default is just a ~ suffix, and there's a common directory relocation many people use to pile them all in a backups directory somewhere)
As another, I wanted to be able to punch a button and drop the current datetime into a file, for files where I keep records and the like, so I added this:
Albeit, you needn't shell out to get a date in emacs, I dropped in in their years ago on a whim and just used what I knew at that time to toss it together.`(insert (format-time-string "%c"))` should do the trick, though you might need to change the format string to taste.
I do this everyday with Emacs live editing a Clojure process.
well if you're in emacs you can C-x C-e evaluate whatever, and if you eval an edited version of whatever function emacs is calling, it just works as emacs calls the thing by symbol name; conceptually it's basically your editor is an elisp repl, so everything can be changed at any time (in general, things like defvar you'd need to setq and so on)
What package do you use to interact with claude?
Not who you replied to, but:
I use agent-shell and I love the ecosystem that's being created there:
https://github.com/xenodium/agent-shell
And for claude interacting back with emacs:
Some folks like having an MCP package. I agree that gives you a bit more control. But I live dangerously and run emacs in daemon mode and tell claude to just run emacsclient to execute elisp as needed. It works amazingly well. Claude has full visibility into my editor and together we can pretty much do anything.
In fact, I increasingly think of emacs as just a live lisp machine. It's a surface that I and the agents can interact against. It acts as a document store, database, control surface, etc.
claude isn't the repl. emacs is the one that made it possible for claude to "iterate". claude isn't even "iterating" you are telling it to.
35 years in my case, thanks to Jean-Jacques Lévy of INRIA. But Emacs was started by James Gosling, not Stallman.
I've been getting into emacs somewhat recently and really enjoying it so far, though I do worry a bit about how much it can do and whether it will lead to any sort of "oops, you opened a project that had a thing that autoexecs or exploits a parser and now you're pwned". I know that's not a unique problem to emacs, but it feels like the enormous amount of things emacs can do gives it a bigger attack surface for that (and I don't know my way around it well enough yet to be confident that I've looked at all the places that might happen)
Maybe the solution is that I should just be running the entire thing in a sandbox in any case.
Actually, Emacs might be handling it pretty well. Safe eval of local variables is a thing. Of course, in your own code, anything goes.
I am too young to be in the 30 year club but Emacs has served me well for more than a decade. I don't use it as a daily driver anymore but it holds a special place in my heart.
Using magit made me believe again that really good software can exist and that there are really great designers still among us.
Also super agree that Stallman's original ideas are only ever more increasingly valid. I will generously say that Stallman has been an imperfect messenger but the core message has always been solid. I have not regretted my FSF membership over the years.
50 years old and feels more modern than any of the crap folks try to sell you "as the editor of the future". Emacs is the true editor of the past, present and distant future.
Modal editing was supposed to pull users away - Evil mode made vimming better. LSPs were supposed to kill it - only made it better. Electron-based crap was supposed to make terminal-native editors look ancient with a built-in terminal, extensions, and a polished UI. Emacs got vterm, eat, and ghostel. GitKraken-like GUIs were supposed to make the git CLI unnecessary. Magit is widely considered better than any git client that exists, GUI or not. Tree-sitter was supposed to require a "real" language server architecture to get accurate parsing. Emacs 29 absorbed it natively, and font-lock, indentation, and structural navigation across major modes got noticeably better. Obsidian and Notion keep trying to overcome it - Org-mode just keeps getting better. AI was supposed to make it outdated - only enhanced it.
For half a century, humanity has been searching for an Emacs-killer. All the while, Emacs has been a killer app all along.
I like it infinitely more than anything, but it also still feels like a comparably slow, crufty pos that will probably die because of how anti-AI half the core community is. Regardless of how good magit is, it's slow.
I also can't understand how people like eca and agent-shell so much unless they've never actually used any decent harness. Neither seems to really fit with emacs. Acp is the exact opposite of extensible, and eca isn't really extensible either.
According to `git blame` the oldest surviving code in GNU emacs is:
being unchanged since 1986-09-12.(It is said the Stallman maybe have kept some of Gosling's older code but I haven't gone back that far.)
Agreed with all of this! To date, agent-shell.el is my favorite AI coding experience.
eca and gptel remain my main "bread-n-butter" atm.
I'm using claude-code.el. What am I missing? (Aside from integration with other models of course).
I have used gptel a while ago which was great for completion-like workflow, but abandoned when I moved to more agentic stuff.
The biggest value of gptel is its API. I can send a request anytime, anywhere, from pretty much any buffer. I sometimes ask things in the middle of typing a message, or I can ask a model to reword the prompt I'm about to send to another model.
Doesn't work with my github enterprise with entra sso integration. I left a question on github gptel but no progress as of yet. That drove me to agent-shell which requires a cli but works.
Yes, Emacs was designed almost perfectly 50 years ago to integrate with modern LLMs.
They had ELIZA and then the Emacs doctor, the rest is just scale.
We just got lucky. Emacs Lisp, unlike most other Lisps that are data-oriented is particularly text-oriented. If instead of LLMs we've gotten LGMs (Large Graphics Models), Emacs wouldn't have time to catch up and keep the pace with other graphics-oriented IGEs (that would've replaced IDEs)
Luckily (for us), Emacs is the king of text-processing and text manipulation.
I will say in regards to the electron editors, wrangling emacs frames and windows can range from a chore to painful. That is one area we can still improve on!
I grokked display-buffer-alist and never had any problems since. With any other editor or IDE (and I used more than a few), it never occurred to me to even want to do anything complex with window placement. There are things I would love to see getting improved in Emacs, but managing windows and frames is not the one.
I think your perspective is perfectly valid, and I'd never advocate for dumbing down display-buffer-alist, but I do think some sort of package which makes common buffer configurations easy for novices who haven't put the effort in would make a big difference without getting in the way for those who've already grokked it
> some sort of package which makes common buffer configurations easy for novices
Experts often do forget their own "beginner's journey", but I honestly never remember struggling with where windows do appear in Emacs. Either because I never had any eccentric expectations of how this should work, or maybe because I had far bigger issues back in my beginnings. Maybe I didn't notice anything until I found Spacemacs, which had just started gaining some traction back then. I don't remember if they've done anything to improve beginner experience, but then, moving off Spacemacs I might have gotten annoyed, which iirc forced me to understand display-buffer-alist. And then trying Doom, I believe I had to explicitly disable all their novice-aimed improvements and rely on display-buffer-alist settings I was already comfortable with. So, I guess it's a difficult balancing game - need to make it intuitive for the beginners, while not screwing it up for the experts. I mean, if Emacs v32-33 ships with "improvements" that somehow mess with my display-buffer-alist, I'd probably get mad for like two minutes. But that's me, if anything like that to happen, I'm sure it will generate some 2000-message-long discussion thread on emacs.devel.
I programmed in Emacs in a myriad of different languages, I used it to write my thesis, to write my homework and later to grade them. I’ve used it to publish countless blog articles, wiki pages and technical documents.
I read that I was hired at my first job from en email received inside Emacs, I’ve used it to send countless emails to colleagues, employers and business partners. I planned both my personal and professional life inside it, I’ve used it to track the time spent doing a certain task when no such software was yet available.
Most of the time I’ve spent in front of a computer over the last 20 years, was inside Emacs. Happy Birthday, Emacs! You’re the best thing that happened in the computing world.
Is anybody here consciously trying to keep their Emacs configs/setup "lean", minimalist, as small as possible?
I'm not a coder, but I did use Emacs daily around 2010-2012, with brief returns later. I always gave up eventually because the complexity of addons, the org-mode-can-do-everything-so-I-should-do-everything-with-it etc just grew over my head. I've discovered that I like Plan9 Sam, Acme and, in general, the one-thing-well camp better. Each their own, I guess.
That said, I did often like how "immersive" using Emacs can actually be at times. I'm a trained journalist, and it made managing bits of information, including PDFs etc, really streamlined, almost like a wonder. And, I had my own little OS on a USB stick that way (though the minimalist in me always whined that "an editor" should not weigh 100+ megabytes).
Incredible that it has been around for 50 years, with no signs whatsoever of being a "paradigm of the past".
I've been using emacs for ~15 years. I don't now what is considered lean. My init is 343 lines. Probably removing all the comments and junk collected over the years it is likely ~200 that actually does anything useful at this point, I should probably clean up. I use emacs everyday. I get the desire to want to do everything in emacs but I also don't. It is good at what it does, it happens to do other things too but I don't know if that is the best way to work.
I've been using emacs for around 30 years and your comment made me curious. My .emacs is 237 lines. It used to be more, but I cleaned out the Java and Octave support I wasn't using anymore.
Kinda, I don't mind having quite a few packages but they are mostly self-contained in their use-package blocks. This way even if things go wrong it's usually just one package I gotta remove and not something that's intertwined with the whole config.
Using emacs for 4-5 years now and it's been a fantastic experience so far.
> Is anybody here consciously trying to keep their Emacs configs/setup "lean", minimalist, as small as possible?
How small? I try for things to not get out of control and as I ofc version my config, I semi-regulary remove stuff I don't use anymore from my config.
But I take about 3 000 of custom elisp, written over the years, doesn't qualify as lean and minimal?
Now I gotta say: I saw packages making it into the main branch and that simplified my configuration. For example eglot: I just adopted it.
> keep their Emacs configs/setup "lean"
With my last bankruptcy where I tried to dissect my 12K LOC config to identify the bloat and the crap I no longer needed, I found very few pieces that weren't used. Turns out, my config was already modular and lean, in the sense that everything I had there had a practical reason to be in there.
Once I started using LLMs to deal with Emacs, I decided to add a bunch of tests to run them in CI, just to prevent regressions. My config since then has grown to 26K LOC + 35K of tests. I consume 250 third-party packages, plus about 100 built-in libs.
My Emacs starts and loads within a second. I have no problems such as freezing, breaking or leaking memory. With all this stuff I have in it, it can run for days and weeks and its memory usage on Mac stays within a comparable range with the Slack app - around 500MB.
I never understood this obsession with keeping Emacs lean. Bruh, throw some shit into it, let it burn, it'll chug on any large amount of Lisp and still give you the smoothest ride ever. What's the point of keeping a colossal beast under a mountain and feeding it a low-calorie diet? It's like digital abuse. Emacs these days is capable of rendering Doom-level graphics, it's offending to use it like notepad.exe.
I had a similar experience where I tried to declare bankruptcy after havning not used emacs for a year and a half or so, ended up re-implementing things until finally I was like 'no I was right the first time'.
That said, damn, my emacs config is like 1000 LOC and takes like 20 seconds to load. Also the reason I keep leaving Emacs is definitely the complexity of the bugs and the edge-of-the-edge case things that come up when I'm just trying to do something simple (the other day it crashed after running `e: newfile`, the evil mode command for editing a new file. I have no idea why it crashed but after it did the program couldn't be killed. Maybe it was because I was trying to open a file with no extension, but even that's a stretch.
Anyway would you mind if I sent you my config sometime or looked at yours? It's never occurred to me to write regression tests
Of course¹, but I warn you - it may feel massive, I do tons of (at first) seemingly weird stuff. Like OCRing images in my clipboard (which is now a separate package²)
---
¹ https://github.com/agzam/.emacs.d
² https://github.com/agzam/clipimg.el
> Is anybody here consciously trying to keep their Emacs configs/setup "lean", minimalist, as small as possible?
Me too, for some reason. I've been using Emacs for 8 years and my init.el is 94 lines long. I guess the defaults mostly work for me.
I usually just use Prelude for some modern defaults
I ran Emacs for ~25 years with almost no custom configuration. I could not be bothered, and the defaults were great
In the last decade I have started to add configuration. When GPT-3 became available, and I did not have to learn Elisp (another f%^&*n computer language - with no other use) I have extensively configured my Emacs
My point is it is very usable with no config
> though the minimalist in me always whined that "an editor" should not weigh 100+ megabytes
Heh. At work many in our department installed a (voluntary) tool that logs the apps we have in memory, and how much RAM they consume.[1]
My manager came to me and said "Your Emacs is taking 8GB of RAM?!"
Guess we should call it EGACS now.[2]
I had an LLM do some debug and it turned out my copy of Emacs is a bit buggy in MacOS. Every time I open a new frame, and then close it, it doesn't release a lot of GUI related stuff. Over several weeks, this leak adds up. I open new frames multiple times a day.
And of course, I got the LLM to make a package I can load in Emacs that cleans it all up without needing to quit.
After cleanup, it's taking "only" 1.5 GB of RAM.
[1] Company is dramatically reducing the amount of RAM on new laptops, so we want to gather data to show it's too little RAM.
[2] For those who don't get it, a common joke decades ago was that Emacs stood for Eight Megabytes and Constantly Swapping. Back when 8MB RAM was huge.
> Is anybody here consciously trying to keep their Emacs configs/setup "lean", minimalist, as small as possible?
I tried but most of my config is just variable settings (with the use-package macro). I don’t really have custom code there. If I do think about a feature, I tried to build a package instead (like one for bridging subsonic and emms).
> If I do think about a feature, I tried to build a package instead
I suppose this is actually the way of keeping a "lean" Emacs.
After a couple of years of detour I’m back to using Emacs since all the fancy lsp, debugger etc stuff in VSCode and Zed doesn’t matter as much for me anymore and I am just more productive with Emacs. But I am still using it like it is 2020. I hear people using coding agents to make crazy customizations to their emacs config and I can imagine Emacs is particularly suitable for this.
Curious what are the biggest things that have come out in the last year or two, and what emacs based personal software have others reading this made?
Native compilation is now default, so elisp is much faster than it was out of the box.
Tree-sitter support is quite smooth now, with automatic grammar installation.
Apparently very good Android support.
Canvas support is in master, people are building all kinds of crazy stuff[0] with this
Lots of nice built-in packages like modus themes, eglot, which-key. Editable grep/xref/occur results is also built-in now. New context menu things.
Load the "newcomer-presets" theme to enable stuff that newcomers tend to want enabled (tab bar, fancy completion, lots of little things).
[0] e.g. https://monadicsheep.org/blog/an-introduction-to-canvas-in-e..., and https://www.youtube.com/watch?v=61-uNV9N154 / https://github.com/yibie/exc.el
Fantastic rundown, thank you!
Wow I missed canvas support completely. This is going to make some custom UI's way easier to make compared to the hacks I had to resort to in the past [0]
I do hope one day we'd get a new cross platform performant display engine that draws like Zed does for more UI capabilities in Emacs. Neomacs[1] promises this and has some of this but looks like its suffering from never ending scope creep and continuously moving back and forth between 80% there and 90% there due to unattended agents running wild.
[0] https://github.com/ozanvos/emacs-webkit-color-picker
[1] https://github.com/eval-exec/neomacs
It looks like exc.el is built on top of a reactive UI framework, which, well, would have been incomprehensible to the first users of GNU Emacs on PDP-11 UNIX…
https://github.com/emacs-taf
Reminds me of https://github.com/emacs-eaf/emacs-application-framework which I've never been able to get to work. I guess this is peak personal software.
> biggest things that have come out
Just ask Claude or whatever to hook up gptel and eca (or agent-shell). You don't even need to read anything, just literally talk to the LLM. The first step is to get to the point where agents can change Emacs from the inside out - and then, that opens the floodgates for any ideas.
Just yesterday I decided to make it possible to detach a video I'm watching (and of course controlling directly from Emacs) from my browser. The active YT video stops playing in the browser, loads mpv, and seamlessly continues, while keeping the time, speed, and volume. It's now possible with the new Canvas API to play videos directly in Emacs; at some point I may try to figure that out. Why? Well, just because I can. With Emacs, the limit is your imagination and nothing else.
Craziest thing? I never had to restart, recompile, rebuild anything. I was watching a video, thought: "hmm, a floating window would be nice..."; without missing a beat, just typed the prompt and made that happen within minutes.
not big but i'm still happy about how it allowed me to build a really expressive musical tracker with micro-tonality implemented by default. partly by Csound score paradigm but we also have an interesting macros, a scale paradigm for adding notes and real-time p-field information
[0] https://github.com/luqtas/csound-score-emacs
About two or three months ago I ditched Neovim as all the complicated modern crap wasn't working for me, and instead of reverting to Vim, I switched to Emacs and Doom + eVil, and am relieved to be back in a nice stable system again. I did ask GPT to port over my key commands and shortcuts, which it did, and things are great again!
Hats off to Stallman. It's absolutely crazy how it stays relevant for such a long time.
We should all learn from Emacs about software longevity.
Stallman’s Principle:
The extension language should be a full featured programming language in its own right capable of creating substantial applications because that is something people will want to do!
I wish every application worth putting a plugin system in it followed this philosophy.
> I wish every application worth putting a plugin system in it followed this philosophy.
Does it open the door for compromising on the core XP whilst expecting everything to be a plugin for example? It's also making the task of testing N^2 complex.
Sometimes a well-thought-through plugin system is no plugin system. Kakoune (https://github.com/mawww/kakoune) is a good example of it.
I know it's an Emacs celebration party, but that one decision made Kakoune super stable and nice to use. (I'm looking at you NeoVim).
>Does it open the door for compromising on the core XP
in some applications yes, in Emacs I'd say no because Emacs itself is extensible and let's people utilize its own core functions and is itself almost like a mini OS. For example the completion framework is enhanced rather than replaced by plugins like Consult.
There's a systems thinking aspect to Emacs plugin development. People make plugins always with Emacs itself in mind and to improve Emacs rather than merely the plugin. It's very anti-Unix philosophy in that way. Org-mode or Magit are good examples of this, they work well, and really only well, within Emacs.
It's what I've struggled with every time I tried out NeoVim where I ended up with ten plugins all loosely held together by tape and always something broke when something else was updated.
I started using Emacs at the AI lab in 1978. It's still my main development tool and probably still the program I spend most of my time in today.
I named my cat Emacs, and he's only three years old. His sister's name is Pip.
And to answer the question I get a lot: no, it would be morally reprehensible to name a cat after an inferior editor such as "vi".
I often thought that a cat could be named /bin/cat. After all, many cats seem to enjoy being in boxes or bins!
You're likely aware of this, and certainly Don is, but for those unaware, PIP was the RSX-11 and CP/M equivalent to /bin/cat.
https://en.wikipedia.org/wiki/Peripheral_Interchange_Program
I'm going to name my next cat after my favorite Apple ][ DOS command:
]CATALOG
And my next dog after the way you warm restart DOS after you hit RESET with Integer Basic ROMs and get thrown into Woz's system monitor:
*3D0G
https://en.wikipedia.org/wiki/Apple_DOS#Technical_details
And his brothers /bin/bzcat, /bin/pacat, /bin/netcat and /bin/sqfscat.
I can only imagine that Pip is an orange cat with typical orange cat characteristics like being crazy and breaking things occasionally.
You are correct: Nominative and chromatic determinism strikes again!
Emacs is a powerful, flexible, majestic, extensible silver tabby, so he also acts like his namesake: textual and functional determinism.
But does he have a gap buffer?
He is cute though.
you can get a dog and call it vi
I’m a cat person but I also am fond of dogs so I would consider that unkind.
I still think you should have called your company Wingnut instead of Cygnus.
What a deeply strange article. It starts out deep in the details of Emacs' origins, then suddenly gives up, fast forwards and ends with a whimper.
ps. My first sight of the author was in a basement lab at the Weizmann Institute in 1986, sitting cross-legged on a chair working in front of the then-wondrous brand new Sun workstations - the so-called "3M standard" (1MB of RAM, 1MHz CPU, 1M pixels). Good times but old times!
Finally, because of the LLMs, i'm in Emacs Religion. I traed it before many many times, being defeated always by a config file, by a module not working, etc. But with WSL, Claude and Doom Emacs, problem is solved.
I realidad that integraron it with tmux and claude cli, it is un unbeatable program.
About 10+ years ago I found a guide on Helm [0] and a guide on Org-mode [1] when I was just getting into Emacs. This helped me move on from using Spacemacs to making my own configuration.
I no longer use Helm (I'm doing Vertico/Orderless/Consult), but I've stuck with Org-mode since then. I sometimes venture out to other apps (like Joplin, Obsidian, Apple Notes, Apple Reminders, etc), but Org-mode just works best for me.
I don't even use it's most advanced features. The most complicated thing I do is maybe recurring schedules and using the agenda. I don't even have agenda view defined (although I really should at this point, it would be really helpful).
I use it every day at work with a daily log.org file keeping track of what I did each day, a habits.org file for recurring tasks I want to make sure I do (check my email, find a PR to review, etc).
I have various files to help organize my personal life - I heavily rely on Beorg [2] for that.
Looking back on my years with Org-mode, I feel like the primary reason I use it is for the ease of use with keybindings and dealing with plain text. I don't need to dig through menus or swipe around. I just go in and type, write, and delete.
[0]: https://tuhdo.github.io/helm-intro.html
[1]: https://doc.norang.ca/org-mode.html
[2]: https://www.beorgapp.com/
emacs is really something apart, by far the best software I ever had the chance to interact with, the closest thing we ever got of a lisp machine, a completly hackable, self documenting programming environment where you can change anything without limits.
It's unfortunate its underlying ideas aren't more widely used in our industry, the very idea that you don't need to expose a separate API for people to create and extends things since code is the api is a idea that put emacs on a league of its own .... Thank you to anyone who has been involved in developing it.
Also I would love to hear Stallman view of labs using (A)GPL code and not contributing back to the world since this is completly against not only the ethos of free software but what Stallman teached to the world about the very purpose of its license
A coworker of mine launched a Windows port (clone?) of emacs when he came in for the day, and never left it for the entire workday --- always envied him his facility with that, but never quite got comfortable with it (and even in a fit of pique gave away a printed copy of the LISP manual which I kind of regret now).
The ironic thing is I've been fascinated by similar graphical efforts such as the Glamorous Toolkit.
Emacs natively support Windows
Good opportunity for us Emacs users to proselytize: send an intro video to a few people who don't use Emacs but should :-)
https://www.youtube.com/watch?v=mJZDmO5yOxE
Also:
Interview with an Emacs Enthusiast [Colorized]
https://www.youtube.com/watch?v=urcL86UpqZc
Deldo - Vibration Control and Teledildonics Mode for Emacs
https://www.youtube.com/watch?v=D1sXuHnf_lo
I have yet to find a reason to switch away from emacs as my primary work flow editor. I've been using it for at least 30 years now.
Why do I prefer it to (say) Turbo Pascal or Borland C++? Both of whom "Visual Studio" style environments have inherited a lot from? Well, those two worked well when one didn't have multiple consoles or terminals, and on a single tasking OS (DOS).
I do not want or need my editor to be my whole UI. (I know Emacs can do it, it's just not something I either want or need). And I am not comfortable with a UI that demands changes from Emacs in order to function, as any such UI suffers from blocking effective development, especially for (say) embedded code spaces.
Can there be better than Emacs? Yeah, probably. It's certainly not the most intuitive interface, for instance.
Is there?
No.
My biggest regret in life was that I was introduced to vim before emacs and got really comfortable with it.
Did not realize that everything I was building in my vim configs to make it better was already default in emacs i.e dired, compile mode, magit, org mode, etc.
If I wasn't able to multiplex with tmux I would have switched to emacs a long time ago.
I love emacs and have been using it daily for about 5 years now.
Many people have mentioned magit and org mode. I just want to give another shout out to consult.el which is a wonderful way to grep and search through text.
Happy birthday emacs!
I was very fortunate: Yale CS already used emacs in 1981, and offered local high school students the chance to take their classes. By the time I got to MIT a year later, I didn't know that there were any other serious editors available!
TFA begins before GNU Emacs proper, but, still: does age and portability make Elisp the ultimate write-one-run-everywhere language?
I got a nice case of emacs pinky back in my early 30's. Had to take disability, get physical therapy to rehabilitate, etc. Been vi all the way since then.
Thinking someone has made the wrong editor choice is a great example of feeling strongly about something that’s meaningless and likely uninformed.
Find it useful to conjure up cognitive dissonance and practice letting it go.
You’re taking this way too seriously.
Been using an Org file containing all my projects as the tracker for each, with a little custom tool that wraps emacsclient as the driver which my agents use. It's been pretty great, but the single-thread bites as it can get wedged sometimes and then I have to go hit C-g.
I quit being an emacs tourist about 5 years ago, this year I started rewriting my init.el with use-package and the popular packages (vertico, eglot, etc). My config is still a mess and there’s always something new I want to do. Sometimes I think about trying neovim or trying some editor that I wouldn’t have to config stuff that much, but I think I’d want to customize things a certain anyway.
For LLM stuff I’ve been using eca, or claude code in a vterm or ghostel. I’m still experimenting with this stuff but I don’t think emacs is getting in my way. Not sure if I’d recommend to everyone, though.
It was great to use during college years.
I regret ever using X/Emacs for 5 years with two reasons.
The biggest reason is, I have arthritis on my left pinky thanks to Emacs. Now I need to use an expensive ergo keyboards (thumb for ctrls)
The second reason being, vi is what I am forced to use for many linux default editors. I never learned it, and always look up google for commands.
(optionally, extending Emacs is pain as I never understood the point of lisp).
I started using the original TECO based Emacs on TOPS-20 at CMU in maybe 1980, so much better than the line editor of the time.
And I used Emacs (on Linux) this morning.
Let me know if you remember the DEC20 and the dreaded “not running” message that happened to everyone in the room when it went down.
Also interested if you remember Gosling Emacs, the first rewrite for Unix. James Gosling of Java fame.
I was lucky enough to have access to TOPS-20 at WPI in 1986 - 1988 (The DEC-20 was replaced with an Encore Multimax running UNIX as the student mainframe). TOPS-20 had a bunch of editors, I tried them all. I remember TVI, TECO and EDT, but I'm sure there were more. I already had experience with WordStar (C and assembly language programming on a PC) and various line editors, so although I used it, I never became an Emacs fanatic.
The most important software missing from the new Encore UNIX (Umax) was MM- the TOPS-20 integrated mail and bulletin board program. A friend of mine wrote "bboard" a campus messaging system as a replacement (this was soon replaced with USENET). It had a bad integrated editor, so I wrote my own editor as its replacement, this became the editor JOE. Even so, Emacs was always there as the counter-example. In those days, Emacs was large and slow and had a limited file size, and it was easy to do better if you weren't focused on extensibility.
I don't remember "not running", but I certainly do remember those annoying "garbage collecting... done." messages in C Emacs. The eventual solution from the mid 90s was kind of awesome: improve the garbage collector? No: Just stop showing the message.
I remember getting a DOS port of Gosling Emacs on floppy disk at a computer show (there was always somebody selling "shareware" at those). I lost that disk, and for a long time had no access to the Gosmacs source code, but eventually someone sent it to me. Sadly, we can not share it- James Gosling closed it. Some other Emacsen: MicroEmacs, Epsilon, JOVE and JED.
This right here is why I hang around at HN.
Is JOE still your own daily driver, or do you use something else now?
Good times of ISPF on IBM 3090/TSO. First you had to allocate a file on a dataset (ibm hates simplicity) and then you edited the text or copied with the pair "cc/mm" followed by a/b. No keyboard shortcuts, no interactive shell, only a data-entry panel and the incessant "tlac tlac" sound of the 3270 keyboard
I started using Emacs 30 years ago. Used it as my main code editor for 15 years, and as my note-taking editor a little longer. I did write my share of elisp code, had a lot of fun with it, posted on gnu.emacs.sources back in the day, and shared a lot.
Emacs is still my main editor over ssh, so I happen to use it on a regular basis, and the commands are all imprinted on my fingers' muscle memory, so that's quite the comfort zone.
Happy Emacs anniversary to everyone!
Emacs is awesome, but it is unfortunate that on Windows it still only supports x64, which is a legacy platform at this point. Hopefully arm64 will be supported soon as well!
Anyone that wishes the death of Intel/AMD, will dearly miss the PC clones.
or, maybe more hopefully, Windows as a whole becomes a legacy platform soon :)
Emacs is a serious tool, you choose it first and only then prioritize on the OS. It's like complaining that editing videos with Adobe Premiere on Linux is not a very solid experience, or something like that. Well, if you're a pro video-editor and you must use Premiere, then maybe you need a non-Linux box to do that?
I like to tell people that consumer OSes are just Emacs hypervisors. And it's pretty clear which are better or worse :)
It's almost not even funny, but I tangle all my dotfiles from an org-mode file. The files it generates are all read-only - to discourage me from writing in them directly. This makes my OS config semi-immutable. Bootstrapping a system from scratch takes no longer than a few minutes and the biggest bottleneck is properly getting access to that dotfiles.org and installing Emacs. This has worked for years and that's why I never had to really learn Nix. I guess Emacs for me is the "true OS", and whatever on top is "just kernel stuff"
Ask Valve how it is going with their plans to drop Proton.
Proton is the shim for backwards compatibility with a messy legacy system. We've all been there.
And we've also seen how legacy systems refuse to die :(
that's like asking linux to drop posix :D
Source?
What source? It is quite obvious without Proton there are no games for SteamOS.
If you're feeling curious at trying Emacs out for the first time (or just want to see what's new in the past decade or so), may I humbly suggest you take a look at my starter config: https://codeberg.org/ashton314/emacs-bedrock
When I first started using Emacs, my dad gave me his config. (Yes, I actually experienced https://xkcd.com/297/ irl.) A few years ago a friend of mine asked for some help getting a simpler Emacs setup—they wanted to move off of Doom Emacs. I made Bedrock as a bare-bones starting point that focuses on built-in customization and understandability. Even if you're comfortable in your own setup, you might find something useful in the files there. :)
For me one of the main attractions of Emacs is I can use it in a terminal over a shitty wire, or on the desktop with all Gui bells and whistles.
Same in both places. Bliss
M-x animate-birthday-present Emacs! RET
So here's an embarassing confession for the occasion:
I code in Emacs almost every day. I read and write e-mail in Emacs almost every day. I take notes in Emacs almost every day. I maninpulate data in Emacs almost every day. Yet I don't know LISP (any LISP!) at all, I barely use any packages beyond "whatever it is that Debian ships by default", and I'm quite bad at fancy Emacs shortcuts. My Emacs config file is a hodge-podge of little snippets I don't properly understand – and it measures in at just about 100 lines, including comments and whitespace, with a significant part of that being just mundane configuration data for the mu4e Emacs client!
This has been the case for about 15 years now. And I'm the kind of person who really likes to know my tools. It's such a ridiculous situation! I somehow never get properly around to sitting down and learning, and I really struggle to make LISP click.
Sigh. I hope I'm not alone. I really really really should learn this thing!
Anyway, the most important part is: Despite all of this, Emacs is still fantastic for me! Here's to the next 50!
> I don't know LISP (any LISP!) at all
I'm a Lisper. I switch between Lisp dialects, sometimes multiple times a day. Since I got my LLM harness to work from inside of Emacs I no longer need to even look at Lisp that it generates for my config.
It is very justified use of AI - if anything breaks, it breaks for me, and mostly just for me. And whenever something doesn't work as expected - I don't even try to debug it anymore - my harness has introspective capabilities - it can run the profiler, monitor changing vars, debug and just fix things.
Now is the best time to try Emacs. If people before could complain that Lisp is weird and not easy to grok, it's not a valid complaint anymore.
Been using Emacs for 37 years. Didn't start learning Elisp until 6 years ago. It's never too late. Wrote an Elisp Cheatsheet for Python Programmers, which helped me level up. Perhaps this might as helpful to you.
https://kickingvegas.github.io/elisp-for-python/
I find it interesting actually. Not embarrassing. You mastered the feature layer more than I. I went into lisp with dreams of making my own features but turns out I was quite limited.
Different psychologies
You're doing it right. When I was gainfully employed, emacs was purely a black-box means to a greater end, i.e., promotions and added responsibility. In my premature retirement, the vortex of emacs became an end unto itself. Believe me, I'd happily trade my emacs expertise for a more meaningful pursuit.
I've been using emacs everyday for the last 25ish years. Although I do read elisp and occasionally write some, I'm far from fluent. You do not need to know lisp to use emacs (although it is funny you didn't pickup some just by osmosis).
We have finite time in our lives. I'd argue it's eminently reasonable to spend time on things other that Emacs' guts, unless that's what tickles your interest.
You may be the most productive emacs user.
emacs is a rabbithole and the cost is rarely worth it. LLM agents do a great job already customizing your configuration for you.
> LLM agents do a great job already customizing your configuration for you.
I'd rather leave it unconfigured than have a massive configuration I don't understand.
You can always read the generated code and spruce it up or have the LLM refactor it to your liking.
Reading code in a language you do not understand is not a way to understand.
I've always told people: You can be a power Emacs user without learning elisp.
I myself used Emacs heavily for 9 years before learning elisp (clicked on my 3rd attempt).
IMO, the included Elisp guide is not good for beginners. My recommendation:
Separate the language from the ecosystem. First focus on simply learning the basics. How do you set a variable? How do you write a loop? How do you write a function? These things are as easy in Elisp as they are in other languages. Perhaps use Exercism to practice.
Of course, also learn the related keybindings (C-M-x to evaluate, C-x C-e, etc).
Only then start understanding some of the basics of integrating with the rest of Emacs (unwind-protect, save-excursion, save-restriction, etc).
I lived in Emacs for most of my professional live, but IDEs and now Claude have taken over. Sad, but perhaps justified? Back in my academia days, there was much less pressure to use a uniform tech setup across staff, so people were happily using Emacs, or vim, or whatever -- and frankly, there was never any issue because of that.
But I can see there is a value (mostly for the admins, but also for debugging if you work collaboratively in a team) in enforcing the same setup for everyone. Sigh. Strangely, I could never convince my coworkers to ditch their IDEs for Emacs.
> IDEs and now Claude have taken over
100% completely opposite experience. Emacs is hands down the king of any kind of text-manipulation. And not only on the composition side. Most editors and IDEs are focused on the composition side of things - making text, adjusting text, amending text. And code btw, is nothing but structured text.
Emacs opens gates for text consumption - I'm reading this entire HN thread in Emacs, just like I consume Jira, Slack, Telegram, Reddit; control YT vids, my browser tabs and history, etc. I search through Splunk and Datadog logs, Wiktionary entries and just general googling - all done in Emacs. I browse million-line codebases on GH without ever having to clone them. If there's a piece of any kind of text in the computational vicinity to my active Emacs instance - this laptop and all connectable devices, I can easily make use of it.
And this gets incredibly important in the age of LLMs. I can read, manipulate, navigate, search through, diff, sort, group, slice, dice, salt and pepper any kind of text. Give me just about any other editor instead and I immediately will feel handicapped.
IDEs that are not malleable (by design) are at an exact disadvantage. I can change any aspect of my editor in the middle of typing this very comment without ever losing the state, the context, or my mental focus. No IDE even hypothetically capable of doing any of that.
And with llm-buddy [1] everything I type in emacs gets sent to an LLM, which makes it even more valuable to do more things in emacs.
[1] https://github.com/ahyatt/llm-buddy
Well, there's over 35 (and counting) different Emacs packages for LLM integration. And that's just the ones that were published.
https://www.reddit.com/r/emacs/comments/1uwm3c0/the_state_of...
Don't get me wrong, I totally agree with you re: text manipulation. That's exactly why I find it so frustrating that it's basically frowned upon in my current job. I do use it still, but must do so pretty much secretly at work.
At home, it's a different story.
I believe, Emacs is considered unprofessional in a lot of places?!
Emacs is considered unprofessional in unprofessional work places.
Dictating specific tools without a very strong technical justification is a strong signal that your management doesn’t trust you to make any important decisions.
> I believe, Emacs is considered unprofessional in a lot of places?!
Why would it be "unprofessional"? It's an editor. I've used it in every job since I left college 20+ years ago.
You should have seen the expression on the faces when I mentioned "Emacs" during my job interview...
The only expression I have gotten was something like "Why not vim?" and my response was "Because emacs is better, and I can always use evil-mode if I want the vim bindings". Then it gets installed (by me or an admin) and I use it. I can't imagine anyone actually caring, that's pretty petty of them, or lazy based on your other comment about it being too much work for sysadmins.
> Emacs is considered unprofessional in a lot of places
What? Why? Who the hell would ever forbid anyone from using a tool that literally makes them more productive? I mean, as the Russians say: "If drinking vodka at work interferes with your job, quit drinking vodka... at that job"
The main argument is that having the same setup on all work stations makes maintenance easier for the sysadmins and you don't run into inconsistencies between developers that only come about as a result of different setups.
Good point that navigating, searching and reading text is perhaps even more important than editing in the age of LLMs.
It absolutely is. Consider this. I'm reading this thread in Emacs. Why? Am I obsessed with it? What's the point? Well, I can easily read not just the thread but also the article posted while ignoring all the fluff - graphics, banners, ads, etc. - to extract a piece of plain text.
I can also just ignore every conversation - sometimes, posted urls are more valuable than what people blabber and fight about. Imagine having to extract all the urls on the page. Some might say: "Hey, there's a browser extension for that", but...
a) the extension has its own keybindings, dissimilar UI, etc.
b) it won't ignore HN's internal URLs, so you still need to grab the list of URLs and then remove the ones you don't need in... your editor. So why not just use that, to begin with?
In Elisp, it's a one-liner. You can bind it to a key. I can also utilize sparse tree search, e.g., to collapse everything while leaving every reply that contains a keyword. With imenu, I can jump to any thread. With indirect buffers, I can compare two parts sitting on opposite ends of the discussion. I can narrow to any point, add some text, and then send a request to an LLM.
And guess what? All these things are still the same for a Reddit discussion. So when I use it in Emacs, I can still use the same ways of manipulating and extracting value.
With Claude it feels like you don’t need IDE’s anymore though. emacs/vim are more relevant than ever imo.
True. I'm not saying that corporate decisions always make sense.
one day, one of my teachers convinced me to try Emacs, and I’ve been using it ever since. At first, Emacs looked repulsive, but once you fall down the rabbit hole, you become addicted.
The reason Emacs survived 50 years while countless modern IDEs rose and died is architectural: Emacs isn't just a text editor with a plugin API—it's an interactive Lisp runtime that treats text buffers as first-class citizens.
Modern editors build layers upon layers of IPC, JSON-RPC protocols, and sandboxed extensions to keep the user from touching the core. Emacs did the opposite: it gave the user direct access to the live execution state. You don’t "configure" Emacs from the outside; you mold it into the exact operational extension of your own thought process.
In an era where modern developer tools consume gigabytes of memory just to render a UI tree, there is something deeply grounding about a piece of software from 1976 that still offers the most malleable computing medium on earth.
Some of us would say it is a Lisp programming environment, with influences from Lisp Machines (Zmacs), having a text editor as sample application.
It's kind of striking how that joke post about ed (from 1991) presented Emacs as extremely resource-wasteful
https://www.gnu.org/fun/jokes/ed-msg.html
but I guess trends elsewhere were so keen on adding abstractions that now Emacs is an efficient, parsimonious choice by comparison.
I would, uh, not describe modern emacs as "parsimonious"
GNU Emacs really didn't start until 1984, but I keep thinking it would be interesting to compare Emacs' resource usage to Zed (or Gram). Then I realize I can't be bothered to run either of those long enough to do it.
Compared to VSCode, Eight Meg And Constantly Swapping does sound ridiculously parsimonious in 2026.
> it would be interesting to compare Emacs' resource usage to Zed (or Gram)
The core of GNU Emacs is written in C, and there are GNU-licensed Emacs variants which are entirely written in C. I really doubt anything like a new Zed/Gram fork would perform better than, say, QEmacs.
The so called editor wars seem to be over and emacs has lost. I've been involved with it since the early 2000s and it's still my primary editor. I feel that the users have reduced into a smaller but more dedicated/passionate group which is probably for the best.
You apparently missed the explosion in Emacs activity in the 2010s. I, too, remember using Emacs in the early millennium and feeling like a partisan of one powerful but nevertheless unpopular editor, with an uncertain future. But once the Mastering Emacs blog, Org-Mode, and Sacha Chua came along, suddenly there were so many new packages to install and tips for one's own config, and things like the pure-gtk build brought UI improvements going beyond merely look and feel.
In the early millennium, I as a Emacs user had hardly anyone to actually talk about Emacs with, even on nerd hangouts like Slashdot or the dedicated Freenode channel. Since the 2010s, one can make oneself practically a whole social life around Emacs.