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.
> 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.
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.
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.
> 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.
Oh, I stand corrected. I was confused, I thought Divya did it experimentally first, for the Emacs Reader. Turns out minad really was the one who had the original prototype, and Divya wanted to use it in the Reader, then multi-people effort to make it work on Android, Mac and finally making it into the master branch. And yes, no LLMs - at least nobody publicly mentions any use of them.
>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.
“This is rather as if you imagine a puddle waking up one morning and thinking, 'This is an interesting world I find myself in — an interesting hole I find myself in — fits me rather neatly, doesn't it? In fact it fits me staggeringly well, must have been made to have me in it!' This is such a powerful idea that as the sun rises in the sky and the air heats up and as, gradually, the puddle gets smaller and smaller, frantically hanging on to the notion that everything's going to be alright, because this world was meant to have him in it, was built to have him in it; so the moment he disappears catches him rather by surprise. I think this may be something we need to be on the watch out for.”
AI deals with text files because we've spent ~35 years of free Unix designing an OS that works on text files. So it's only a natural fit because we designed the tools that built LLMs on text-based OSes.
If, say, Apple had made Copland work, or the Lisa had some killer app and proved to be a big hit, we'd be working on natively-OOPS OSes built in Smalltalk-like languages where text files were one encoding, a detail about as interesting and influential as Unicode.
> […] the number of people who deeply grasp Emacs Lisp and Emacs' internals is really small […] AI is not going to encourage any growth in that small elite
I haven’t been all-emacs all-the-time for ages (I jumped back to the other editor after years of emacs), but hasn’t that super-elite group always been relatively small? We have to hope that the best of the next generation are going to self-select and be curious (and hopefully get the support they need from the established old guard) despite AI. We have to hope that the kids (no matter their age) will be alright.
Counterpoint, I’ve been one those surface level emacs users for years and coding agents have been super helpful for me to learn elisp and some emacs internals by hacking on some org mode and elfeed extensions
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.
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.
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.
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.
Oh, definitely. I had had some other shell calls and just followed the pattern. It was fast enough that I never bothered to go back and look up the right way to do it :)
To add to what everyone else is saying, most Lisps support redefining functions in a running application. Instead of the code/compile/test loop most languages use, you can create Lisp programs iteratively from inside the program.
It's really quite neat. Emacs is an easy way to play around with it, but if you're a CS language nerd Racket might be a good fit for you. And if you want this type of environment but without all the parentheses and polish notation, check out the Smalltalk implementation Squeak.
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.
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 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.
> 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.
Same here! Aside from the basic unix tools in /[usr]/bin/, there is very little software with the longevity of emacs. I fully switched from vi to emacs in 1992 and been using it heavily every day since then. So good.
(The only other program I can think of from that era that I still use is trn to read USENET)
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 tried many packages for interacting with AI agents in Emacs, and eventually, as AI became better, I settled on just running them in terminals inside Emacs (ghostel, which is fantastic).
As for AI doing the coding in my Emacs, I simply use Claude Code or codex with the emacs-direct package which exposes the Emacs REPL via MCP. That allows the AI to do quick iteration passes and try things out in my running Emacs. Or start another one for testing.
There's a megathread on r/programming about the Gosling/Stallman legal fight, but long story short, the GNU Emacs we know today was continuously built upon a foundation first laid down by Jim Blandy and Stallman. Very little, if any, code from Gosling, Moon, or Steele survives.
But GNU Emacs was not the first incarnation. That was EMACS on some PDP system in the 70s and Richard Stallman was already involved in that. Gosling Emacs only came years later.
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.
Had the last ten years of emacs development never happened, I suspect emacs would be just as used. So no, I don't think the anti-AI stance would extinguish the compelling repl-as-editor proposition that emacs does so well. I wouldn't put too much stock in the agent-shell business. It's got junior dev written all over it, and they're the most vocal.
> I wouldn't put too much stock in the agent-shell business. It's got junior dev written all over it
This is absolutely uncalled for. Álvaro is a long-time Emacs advocate and maker of packages, long before LLMs. I guess that's why some Emacs adepts, despite their long-time commitment and contributions, refuse to be called "programmers", notably Prot (Denote), Karthik (Gptel) and Jonas (Magit). They all keep saying they are not, maybe just to avoid this kind of ungracious stigma from random people.
Some FOSS developers are one of the rarest kind of people we need to cherish and respect. They who sustain unpaid, often thankless maintenance work on important infrastructure for years, sometimes it becomes their life purpose, with zero direct financial reward, while fielding entitled bug reports. They don't anticipate any recognition, but at least let's not call their work substandard, it's not like you're getting taxed for using it.
Did anyone ever tell you how badly you suck at prophecies? This unfalsifiable prediction has enormously bad track record: people have called Emacs dead since the 90s, through XEmacs, through every IDE wave since, through Atom, Sublime, nvim, VSCode, Zed, etc.
I'm sure "Anti-AI core community" drinking themselves to oblivion and chugging anti-depressants seeing how many packages for AI integration people keep building¹ and they just can't do anything about it. Bruh, there's literally ongoing threads about built-in LLM support in emacs.devel, the latest one is not even a week old.
Magit being slow is almost entirely git subprocess spawn and output-parsing overhead, which exists in any git porcelain, not something specific to Emacs or elisp². Blaming Emacs for that is blaming the UI for the engine. I use Magit on Mac and it is not slow. It is slower than on Linux, but it ain't unusably slow.
Define "decent harness". First of all you're conflating the layers - ACP is a wire protocol; asking a protocol to be extensible is illiteracy - protocols are meant to be minimal and stable, that's literally their job. eca and agent-shell are ordinary elisp, with hooks, advising, keymaps, same mechanisms every other package uses. If that layer is hookable and advisable, it's extensible in every effing sense; extensibility was never supposed to live in the protocol underneath. Darn, I'm extending eca from inside fucking eca buffer, da fuk you even blabbering about? Whatever, skill issue. Next.
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.
Don't tell anyone: https://github.com/agzam/.emacs.d/blob/main/modules/ai/gptel...
There's a fear among third-party Claude tool-builders that Ant will close the shop very soon, making it hard for them to use it. Like they did with OpenClaw. I'm sure some inventive hackers still doing it anyway.
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 want to build it because it would put an experience with the level of power described so thoroughly here onto every device simultaneously. I think it would be an incredible boon for programming literacy.
At the same time we could make programming feel natural to do on touchscreen devices, and in languages other than English. Combined with just having a place to play and learn (a reason to write little programs) my hope is that such a tool could inspire a new generation of programmers who previously were locked out
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.
The ONE thing that has me (so far!) using Obsidian instead of Emacs with my agent has been that org mode on mobile is such a clunky experience. Admittedly Orgzly exists for Android, but at the end of the day, org-mode's UX is designed around the keyboard and it hasn't been well enough adapted to the mobile experience.
I've been considering trying it out anyway and seeing what I can do to smooth things out though. Still really getting a hang of exactly how to best integrate external memory in the form of notes with my agentic setup. Was looking at some second brain approaches (such as Zettelkasten) but a lot of that just feels like throwing information into a pile that is more likely to chew through tokens and not provide much benefit with the AI, even if it might well be a really neat way to keep more old fashioned notes.
If you use Hermes, one tip: `session_search` allows searching through all past sessions via full text search. So you don't need to load the notes in every turn.
Another hard part is that your vault of notes and the agent's memory are separate. They can drift apart.
We, at Substrate, have solved this with our memory architecture. With it, all of your notes are considered as one memory, and we can always attribute a source to each fact.
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".
> 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.
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.
> 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).
Probably, the sign that it is a paradigm of the past, at least partially, are the issues Emacs has with UI blocking and multi-core usage. Great packages manage to mostly work around it, by outsourcing to other external processes and parsing the results, though the parsing happens inside Emacs. The issue and at the same time the enabler of many things, is the ton of global mutable state, that will be very hard to factor out at some point, if ever.
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²)
Crashing Emacs is a rare aberration, GNU/Emacs is incredibly stable, I really don't remember the last time seeing it crash on Linux. On Mac, that could happen, usually due to some .dylib misbehaving, also a rare thing. Don't ask me about Windows, I stopped using it completely and hope to never have to boot into it ever again. Some things in life are just not worth losing your breath over frustration. Anyone who says Windows 11 is not aggravating are out of their mind.
Sometimes, people conflate Emacs crashing and hanging, the latter can happen, but almost never requires killing it - you just send `pkill -SIGUSR2 emacs` from the shell and it unblocks.
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
>When GPT-3 became available, and I did not have to learn Elisp (another f%^&*n computer language - with no other use)
DHH recently said that despite hating Rust, he recently wrote a program he needed in Rust by handing the task to AI, and that the alternative was him having to spend nine months to learn the language.
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.
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.
Probably most of the people who used them a lot at the time would be 55–70-year-old men in the US today. https://www.ssa.gov/oact/STATS/table4c6.html suggests that 88% of US men who would be 55 if they were still alive are in fact still alive, and 72% of US men who would be 70 today if they were still alive are in fact still alive.
So probably three-quarters of the people who remembered them in, say, 01990, still remember them. You remember all those guys, and the occasional gal, you saw at computer stores and user group meetings at the time? Most of them are still alive, and most of them still remember them. They're just harder to find because places like HN have filled up with MBAs.
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.
> It's absolutely crazy how it stays relevant for such a long time.
I believe it's because of Lisp. The majority of the new generation of programmers are mostly just clueless about how Lisp remains relevant and how things in the Lisp-world are calmly and quietly getting just built, problems solved, solutions developed - without fanfare and pomposity.
The biggest digital bank in the world uses it. Nubank, using Datomic as their primary tech driver, grew from ~12M customers in 2019 to 131M in 2025 - almost 1000% growth in less than a decade. Not an exactly faithful comparison, but for JPMorgan getting to their ~80M customers took dozens of acquisitions and 150 years.
Netflix uses it. Amazon uses it. Apple uses it. Walmart built their billing system in it. Cisco's entire cybersec stack is on it. Even NASA uses it.
The number of Lisp dialects just this past decade has exploded - you can find practical, working Lisp pretty much for just about any runtime now. The amount of Emacs Lisp on GitHub alone should be at least surprising - you check the GitHub lang stats, and may think how weird - a non-general-purpose PL, that has always had one and only intent, is among some top languages, why? r/emacs subreddit gets daily, pretty much daily announcements of some new Emacs packages. The age of LLMs is now practically proving the value of Lisp. Working with an AI harness through a Lisp REPL is palpably a better experience - agents work faster, spending far fewer tokens.
It is honestly just baffling how almost every PL out there is restrictive, in the sense that they impose seemingly weird and arbitrary nuisances, while Lisp has always had just two necessities - structural editing and REPL-driven workflow. Those are the only two things anyone needs to grok in order to efficiently build with it. And even these are not hard requirements.
It gets frustratingly exhausting to dispel a constant barrage of biases. As if people just don't want to believe their own eyes to see how pragmatically commonsensical it is and always have been.
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.
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!
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
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!
A deeply strange set of choices indeed, including wasting the last few paragraphs talking about Mac OS.
The post 1970s/1980s history of Emacs is one of the more colorful stories in the software development world. The Emacs/XEmacs schism is the most famous episode, but there's also the "waiting for Godot" drama surrounding the Emacs 21->22 release, etc.
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.
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.
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 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.
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.
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'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'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 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
As others have said, it's never too late to learn.
My life has been within Emacs for 31 years. Yet I would say that I only really learned Elisp in the past ten years. Still at a tyro level, but enough to write my own functions for VM (I don't think mu4e existed when I started using it, also 31 years ago).
>Anyway, the most important part is: Despite all of this, Emacs is still fantastic for me! Here's to the next 50!
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).
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.
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.
> My Emacs config file is a hodge-podge of little snippets I don't properly understand
People giving you truly time-saving advice. Use a good model to unhodge-podge it. You can even ask it to explain every single Lisp snippet it makes, to the detail and granularity level you prefer - want a big picture, please; would you like nitty-gritty details - ask no more. It's not like it's gonna build a "massive configuration" and absolutely will refuse to make it make sense to you.
Yes. "A hodge-podge of little snippets I don't understand" is the situation I'm in and wish to avoid. "An LLM wrote a lot more that I don't understand" will make the situation a lot worse.
There's indeed lots of good advice in this thread. I appreciate it all! "Just use an LLM for the stuff you don't understand" is, however, not one of them.
You're hypothesizing of something you haven't even tried. What's the worst possible outcome? You end up with more shit you don't understand. You then just throw it away and go back to smaller amount of shit you didn't understand well to begin with.
I'm sorry, but I'm out of magic scrolls to turn someone into a Lisp adept in a blink. So this time you really have to convince yourself to do something about it; I'm powerless against your lazy ass here - the curse is too strong.
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
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.
Can you share a few more details? What did llms help you see that you didn't see before? I myself have tried to get into emacs several times but always went back to vs code as it just felt more natural to me
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've been using Emacs since the early 80s, first Gosling's Emacs and shortly after switch to GNU Emacs when it was first released in 1985. In college we had a DEC-10 system and I used Teco on that one.
Just the other day I made this comment on the topic of "nvim vs emacs", I think it fits here well:
> editor choice shouldn't be treated like soccer or religion
Oh, I wish there was a choice here. I've been vimming since 2010, the idea of vim modality is an excellent, practical, beautiful model. It's a fantastic idea and the ideas do port. That's why I've used vim-bindings in every editor/IDE/terminal/browser I used.
Emacs, however, is not an editor. It's a Lisp REPL loop with a built-in editor. The only contenders in this space are Light Table, Nightcode, or Lem and none of them truly can compete with Emacs (at least right now), because you can't just ignore forty years of package development. Maybe some more people start using Lem and keep vibe-coding a huge body of Elisp into CL and then maybe we finally see something that can potentially dethrone Emacs.
It's not sports or a religion - you can feverishly love trains and despise airplanes, but you've got to admit, trains just can't replace airplanes, regardless of what you love and believe in.
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.
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. :)
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.
When I started using emacs it already felt past well-established and perhaps past its prime. Decades later it feels perhaps more relevant than it did the then. The easier-access defaults kits of the mid-2010s got a lot of new user investment, and it feels like the community really ticked up around COVID. Yes, agentic development has us spending a lot of time in harnesses; relevance-wise, things that aren’t an editor feel more threatening than alternative editors. We’ll see how that lands over time! Most of the reason I use a harness outside Emacs is to take advantage of a Claude subscription.
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.
Epsilon 1982 was very much Emacs, but programmable in C. But it loaded superfast in MSDOS palmtop HP100LX. I made lots of Epsilon programs, which were easy to translate to real Emacs, of the fake Unix, made by Linus.
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.
I don't know how long ago "your early 30's" was, but for me this was never a question - I'm a die-hard vimmer, I use vim bindings everywhere. It's practical, why force myself to relearn my typing with every new tool I use if I really don't have to? Emacs, as it turns out, vims much better than any other concrete vim implementation. Even though I did learn some basic Emacs vanilla bindings, I'm still a vimmer. Vimming in Emacs never was a big obstacle for me.
I am primarily an Emacs user, using the standard key bindings (and a whole bunch of custom bindings and functions I've built on top of it over the decades, ctrl remaped to caps lock and no Emacs pinky so far).
But I am also 80% a NeoVim and Vim user for about 15 years now, and I consider myself quite proficient with Vim keybindings. The Emacs emulation is truly incredible, but the fact that Vim implementation quality varies wildly from environment to environment is extremely frustrating to me. For example, the jupyterlab-vim plugin is so jarringly broken in a handful of ways that it completely knocks me out of the flow of whatever I was doing when I encounter those emulation failures. IntelliJ's idea Vim plugin is a pretty decent one, but even there I have encountered the occasional issue [1][2][3]. Otherwise, I strongly agree with your point about learning one way to work with text and being able to leverage it most places.
Sort of a tangent, but I think this is why Emacs users tend to end up trying to do as much in Emacs as possible: It's not really the keybindings but the fact that everything in Emacs is a text buffer. Emacs owns the input and the output, and because everything in Emacs operates on text, you can do most everything in most every mode, to most any buffer content. One example of how powerful this can be is the ability to press a key and use dabbrev-expand to autocomplete shell input I'm typing based off the shell output of a prior command.
> Vim implementation quality varies wildly from environment to environment is extremely frustrating to me.
I know exactly what you're talking about. I am a die-hard vimmer and used vim plugins in every editor/IDE/browser/shell/multiplexer/WM/etc. I use vim bindings system-wide. I control my music, switch between apps, swap and resize windows - all without lifting a finger from the home-row.
I spent almost a decade living in IntelliJ. I had many direct conversations with Andy Vlasovskikh (he's the maintainer of IdeaVim then). Gary Bernhard (Destroy All Software, wat guy) once said: "there's no vim-mode, there's only Vim" in the sense that no single editor or IDE, not a single vim emulation layer properly works, they all have glaring deficiencies - to the point that it can drive any experienced vimmer truly mad.
With one notable exception. Evil-mode in Emacs is just wonderful. It's the best vim-emulation layer, to a certain degree it works even better than in Vim/Nvim. Weirdest thing - it makes you forget it's not a built-in feature of Emacs. I'm honestly very happy with it, because I don't know, otherwise, I might have never convinced myself to ever give Emacs a try.
These two ideas - vim modality and the grand idea of Lisp - are possibly the two best things that I am forever grateful to my younger self for forcing me to learn. I can't even comprehend being a professional software developer and not grokking them.
I definitely agree with this. Literally the only time I use lisp is when working on my Emacs configuration, but after almost 20 years of using it to write all sorts of functionality from big to small things, just having the exposure to lisp has really helped expand my thinking about programming in ways that working with e.g. C, Python, Rust may not have.
One last thing on the Vim emulation front: While I'm not a big fan of VSCode, the VSCode-Neovim extension[0] connects to an actual Neovim instance via Neovim's MessagePack-RPC API, allowing you to use real Neovim but native in VS Code. Pretty cool!
afaik, even with the extension it only affects the editor pane - any other windows still require tons of mouse use. I'm not mouse-nazi, but years of one-handed use of it have created tons of problems for me - in the neck, wrists and my back. All kinds of mice I tried didn't help - magic trackpad, vertical, ergonomic, etc. I'm sure this is pretty common.
I keep thinking of maybe I should learn to become ambidexter mouse user, and if I ever have to become a VSCoder (I pray not), I still may have to. For now, Emacs and vim and reduced mouse use are working.
I think I bought the Emacs Manual from Richard Stallman in 1979, give or take a year. I still live in Emacs, even writing my own AI coding harness inside Emacs.
I suspect that I am slightly more productive in VSCode for large code bases, but it just makes me feel happier and content to use Emacs.
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"
recently our company swithed from cursor -> codex. but we only can use the cli or vscode pulgin. with a few hours, i come back to emacs + codex, and ask codex to do a little tweak. everything works perfect.
there is program called 'doctor' in emacs, it's a rules based 'AI', pretty dumb. and it's like 40 years old. 40 years later, people are still using the same editor, just with diffnert AI program.
this is the most elegant and beautiful software i have ever used. and i wish after a 100 years, people will still love it.
I'm slowly getting into it. I only got into vim (neovim) a couple years ago (been computing as a kid since early 80s).
But have been enjoying learning alot of emacs (oh god so much to learn :))
I'm not ready to make the jump (not sure I will jump at all, but...) I am gonna mess with guix in a vm to see how I roll with that.
I've got a lot of digital versions of various books on lisp/scheme but only played with them. Eventually I think it'd be great to do more with slime/sly and sbcl. But for now sticking with the basics. It's a real head trip to see the power of emacs, and it feels like it's hard to explain to people why it's so fascinating (to me).
I have a feeling I picked a good time to hop in, because a lot of the quality of life features seem to have only come in the past few years.
(my experience is specifically to use vanilla and build up from there, to both learn, and to get used to the "proper" way. I was afraid doom or space would end up getting me into their mental models, and didn't want to feel "locked in")
Of course shout out to systemcrafters, joshblais, protesilaos, sacha chua, mickey peterson (and mastering emacs).
God, I haven't even mentioned org-mode or magit (though magit is still a bit rough, I'm used to lazygit - in some ways using magit is making me understand some things about how git operates better).
The other thing is - I feel like I'm walking on unstable ground when using emacs - maybe it's just because I'm learning, and it's so easy to modify, I always feel like I'm about to break something. I know "backup stable config" and reset from that if it breaks, is obvious; but there's a feeling of looseness that comes from it that's a bit intimidating.
I guess I had that feeling with vim at first to. Obviously it's not going to "break" but as a noob, sometimes it's intimidating and feels that way.
The other thing I need to work towards is mastering workspaces/projects (and maybe tab integration) right now I run server/client windowed, no chrome (no tab, title bar). May add tabs for project management, but I wanted to get used to using M-x for things first (and man does vertico, consult, orderless and marginalia help with discovery!) Embark is another big tool I have so much to learn about.
And seeing how people use emacs for publishing. Linkarzu interviewed an author who talked about he used LaTeX for publishing.
One of my favorite facts is telling people that emacs is one of the oldest actively maintained piece of software still at large. It makes me feel like I'm part of an ancient tradition LOL.
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.
But I've also worked at a different place in the past where - when I asked if I could have Emacs installed on my machine - the sysadmin asked me "What's Emacs?"
> 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.
Develop hacker's mindset. Don't anyone tell you how to use your computer. Especially don't let your computer to dictate you the rules. Always remain in charge.
When I started at my current job, they gave me a laptop that came installed with crap called ABR - Admin By Request. Basically, for anything that required sudo, they'd force me to run it, then click a prompt: "yes, I need the [fucking] access," then another little prompt comes up, asking for "reasons," and you're supposed to type it, to which everyone on my team types some random number of letters (because there's a minimum), then press Ok to get three-hour access.
I dealt with it for exactly three days. After that I just wrote a script that periodically checks if I have the admin rights, and then waits for me to get idle (so no sudden focus stealing), then runs the sucker, sends the request, etc. I don't even see it anymore - just happens. I'm not playing their stupid games, their "security theater", I have a job to do.
> Develop hacker's mindset. Don't anyone tell you how to use your computer. Especially don't let your computer to dictate you the rules. Always remain in charge.
That would be nice in theory. I've worked in many different places throughout my career and in almost all of them, the sysadmins had the final say in what software was okay to install on your machine and which one wasn't.... because "security".
I just gave you an actual, practical example, not a theoretical one.
Here's another one. I wanted to try eca-emacs, the documentation website sits at https://eca.dev, Cisco Umbrella, for whatever stupid reason, blocks the entire .dev domain, and every corporate laptop comes pre-installed with Cisco Secure Client that you can't remove. I submitted a ticket, and then wasted my time on a ridiculous exchange with the "big security guy," who decided to take a power trip and refused to have the website whitelisted. Despite it being absolutely harmless. I don't know where the fuck he's purchased that condescending tone and posture. In the end, I said: "thank you for your time," and hoped to never ever have to talk to him. Then I set up a SOCKS tunnel through my local Linux box, installed the FoxyProxy extension, and voila - I'm never ever going to have to complain about a blocked website.
> sysadmins had the final say
And you can always find workarounds. Those who want to do something look for a way, not excuses. You're a goddamn computer programmer. Maybe act like one.
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.
Very interesting. I was very active on Freenode#Emacs. The Emacswiki and all of those resources. I jumped onto and heavily got into org when I first came across it in the early 2010s I think.
But you're right, it looks like Emacs went on strongly but I fell off the bandwagon.
libera#emacs tends to have around 8-900 users connected (maybe more when the US is awake, probably not everyone uses a bouncer). Both reddit and mailing list are quite active too.
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.
> 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.
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.
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.It told you exactly what to do.
> 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.
> /emacs gets daily, daily! announcements of new packages. Many of them, if not most, are not some AI-sloped trash
Literally unsubscribed from /r/emacs because it was, in fact, trash.
Haven't used the canvas patch but afaik minad didn't use LLMs to write it.
> afaik minad didn't use LLMs to write it.
Oh, I stand corrected. I was confused, I thought Divya did it experimentally first, for the Emacs Reader. Turns out minad really was the one who had the original prototype, and Divya wanted to use it in the Reader, then multi-people effort to make it work on Android, Mac and finally making it into the master branch. And yes, no LLMs - at least nobody publicly mentions any use of them.
>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.
>Lots of recent Linux and neovim users due to how easy it is to debug an issue or edit a config now.
DHH made the interesting point that the Unix standard of plaintext dotfiles and such are as if designed for AI.
> as if designed for AI
Really? Really?
I am reminded of Douglas Adams:
“This is rather as if you imagine a puddle waking up one morning and thinking, 'This is an interesting world I find myself in — an interesting hole I find myself in — fits me rather neatly, doesn't it? In fact it fits me staggeringly well, must have been made to have me in it!' This is such a powerful idea that as the sun rises in the sky and the air heats up and as, gradually, the puddle gets smaller and smaller, frantically hanging on to the notion that everything's going to be alright, because this world was meant to have him in it, was built to have him in it; so the moment he disappears catches him rather by surprise. I think this may be something we need to be on the watch out for.”
AI deals with text files because we've spent ~35 years of free Unix designing an OS that works on text files. So it's only a natural fit because we designed the tools that built LLMs on text-based OSes.
If, say, Apple had made Copland work, or the Lisa had some killer app and proved to be a big hit, we'd be working on natively-OOPS OSes built in Smalltalk-like languages where text files were one encoding, a detail about as interesting and influential as Unicode.
> […] the number of people who deeply grasp Emacs Lisp and Emacs' internals is really small […] AI is not going to encourage any growth in that small elite
I haven’t been all-emacs all-the-time for ages (I jumped back to the other editor after years of emacs), but hasn’t that super-elite group always been relatively small? We have to hope that the best of the next generation are going to self-select and be curious (and hopefully get the support they need from the established old guard) despite AI. We have to hope that the kids (no matter their age) will be alright.
Counterpoint, I’ve been one those surface level emacs users for years and coding agents have been super helpful for me to learn elisp and some emacs internals by hacking on some org mode and elfeed extensions
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.
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.
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.
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.
Oh, definitely. I had had some other shell calls and just followed the pattern. It was fast enough that I never bothered to go back and look up the right way to do it :)
To add to what everyone else is saying, most Lisps support redefining functions in a running application. Instead of the code/compile/test loop most languages use, you can create Lisp programs iteratively from inside the program.
It's really quite neat. Emacs is an easy way to play around with it, but if you're a CS language nerd Racket might be a good fit for you. And if you want this type of environment but without all the parentheses and polish notation, check out the Smalltalk implementation Squeak.
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.
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.
I also strongly recommend agent-shell. I use it for all my work with Claude.
I use claude-code.el plus monet.el, but I have since had claude extend it in many ways, including exposing executeCode through monet /ide support.
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.
how do you use claude from within emacs - is it gptel? just curious. what you describe is worth trying
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.
> 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.
Same here! Aside from the basic unix tools in /[usr]/bin/, there is very little software with the longevity of emacs. I fully switched from vi to emacs in 1992 and been using it heavily every day since then. So good.
(The only other program I can think of from that era that I still use is trn to read USENET)
This comment inspired me to get back into emacs. Had claude rebuild my pi+herdr setup with pillish and a custom emacs package.
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.
Do you have any resource to recommend for using AI with Emacs? As in, aware and able to interact with the REPL.
Or maybe a more fundamental question, how do you find out what are good packages to use?
I tried many packages for interacting with AI agents in Emacs, and eventually, as AI became better, I settled on just running them in terminals inside Emacs (ghostel, which is fantastic).
As for AI doing the coding in my Emacs, I simply use Claude Code or codex with the emacs-direct package which exposes the Emacs REPL via MCP. That allows the AI to do quick iteration passes and try things out in my running Emacs. Or start another one for testing.
Thanks. I assume this [0] is the package you mentioned, even though the name of the repo is not matching, it matches in the command itself.
[0] https://github.com/iflow-mcp/rhblind-emacs-mcp-server
35 years in my case, thanks to Jean-Jacques Lévy of INRIA. But Emacs was started by James Gosling, not Stallman.
That's simply not true. Gosling wrote a commercial implementation, but Steele and Stallman wrote the first versions of Emacs.
There's a megathread on r/programming about the Gosling/Stallman legal fight, but long story short, the GNU Emacs we know today was continuously built upon a foundation first laid down by Jim Blandy and Stallman. Very little, if any, code from Gosling, Moon, or Steele survives.
But GNU Emacs was not the first incarnation. That was EMACS on some PDP system in the 70s and Richard Stallman was already involved in that. Gosling Emacs only came years later.
[flagged]
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.
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.)
It took me a little hunting, so:
https://en.wikipedia.org/wiki/Alternating_caps
Found via:
https://wiki.c2.com/?CapitalizationRules
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.
Had the last ten years of emacs development never happened, I suspect emacs would be just as used. So no, I don't think the anti-AI stance would extinguish the compelling repl-as-editor proposition that emacs does so well. I wouldn't put too much stock in the agent-shell business. It's got junior dev written all over it, and they're the most vocal.
> I wouldn't put too much stock in the agent-shell business. It's got junior dev written all over it
This is absolutely uncalled for. Álvaro is a long-time Emacs advocate and maker of packages, long before LLMs. I guess that's why some Emacs adepts, despite their long-time commitment and contributions, refuse to be called "programmers", notably Prot (Denote), Karthik (Gptel) and Jonas (Magit). They all keep saying they are not, maybe just to avoid this kind of ungracious stigma from random people.
Some FOSS developers are one of the rarest kind of people we need to cherish and respect. They who sustain unpaid, often thankless maintenance work on important infrastructure for years, sometimes it becomes their life purpose, with zero direct financial reward, while fielding entitled bug reports. They don't anticipate any recognition, but at least let's not call their work substandard, it's not like you're getting taxed for using it.
> I wouldn't put too much stock in the agent-shell business. It's got junior dev written all over it, and they're the most vocal.
(completing-read "How should I take this?" '("ouch" "lol" " ̄\\_(ツ)_/ ̄"))
⬑ Xenodium created agent-shell, in case anyone missed the joke.
> Will probably die
Did anyone ever tell you how badly you suck at prophecies? This unfalsifiable prediction has enormously bad track record: people have called Emacs dead since the 90s, through XEmacs, through every IDE wave since, through Atom, Sublime, nvim, VSCode, Zed, etc.
I'm sure "Anti-AI core community" drinking themselves to oblivion and chugging anti-depressants seeing how many packages for AI integration people keep building¹ and they just can't do anything about it. Bruh, there's literally ongoing threads about built-in LLM support in emacs.devel, the latest one is not even a week old.
Magit being slow is almost entirely git subprocess spawn and output-parsing overhead, which exists in any git porcelain, not something specific to Emacs or elisp². Blaming Emacs for that is blaming the UI for the engine. I use Magit on Mac and it is not slow. It is slower than on Linux, but it ain't unusably slow.
Define "decent harness". First of all you're conflating the layers - ACP is a wire protocol; asking a protocol to be extensible is illiteracy - protocols are meant to be minimal and stable, that's literally their job. eca and agent-shell are ordinary elisp, with hooks, advising, keymaps, same mechanisms every other package uses. If that layer is hookable and advisable, it's extensible in every effing sense; extensibility was never supposed to live in the protocol underneath. Darn, I'm extending eca from inside fucking eca buffer, da fuk you even blabbering about? Whatever, skill issue. Next.
¹ https://www.reddit.com/r/emacs/comments/1uwm3c0/the_state_of...
² https://news.ycombinator.com/item?id=49634649
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.
Don't tell anyone: https://github.com/agzam/.emacs.d/blob/main/modules/ai/gptel... There's a fear among third-party Claude tool-builders that Ant will close the shop very soon, making it hard for them to use it. Like they did with OpenClaw. I'm sure some inventive hackers still doing it anyway.
Yes, Emacs was designed almost perfectly 50 years ago to integrate with modern LLMs.
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.
They had ELIZA and then the Emacs doctor, the rest is just scale.
[flagged]
I wonder what you'll think of Paneditor.
It's like "what if the web browser became emacs".
I want to build it because it would put an experience with the level of power described so thoroughly here onto every device simultaneously. I think it would be an incredible boon for programming literacy.
At the same time we could make programming feel natural to do on touchscreen devices, and in languages other than English. Combined with just having a place to play and learn (a reason to write little programs) my hope is that such a tool could inspire a new generation of programmers who previously were locked out
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.
The ONE thing that has me (so far!) using Obsidian instead of Emacs with my agent has been that org mode on mobile is such a clunky experience. Admittedly Orgzly exists for Android, but at the end of the day, org-mode's UX is designed around the keyboard and it hasn't been well enough adapted to the mobile experience.
I've been considering trying it out anyway and seeing what I can do to smooth things out though. Still really getting a hang of exactly how to best integrate external memory in the form of notes with my agentic setup. Was looking at some second brain approaches (such as Zettelkasten) but a lot of that just feels like throwing information into a pile that is more likely to chew through tokens and not provide much benefit with the AI, even if it might well be a really neat way to keep more old fashioned notes.
If you use Hermes, one tip: `session_search` allows searching through all past sessions via full text search. So you don't need to load the notes in every turn.
Another hard part is that your vault of notes and the agent's memory are separate. They can drift apart. We, at Substrate, have solved this with our memory architecture. With it, all of your notes are considered as one memory, and we can always attribute a source to each fact.
What notes does your agent use in a given session? https://trysubstrate.co/l/a2hn
https://old.reddit.com/r/emacs/comments/1xityhe/bloom_now_av... people have been making so many android org apps lately
Strangely enough, the lack of Grammarly integration stops me from using Emacs entirely (after being a zealous user for years).
Let me know if this has changed!
https://github.com/emacs-grammarly
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".
> 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.
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.
> 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.
Probably, the sign that it is a paradigm of the past, at least partially, are the issues Emacs has with UI blocking and multi-core usage. Great packages manage to mostly work around it, by outsourcing to other external processes and parsing the results, though the parsing happens inside Emacs. The issue and at the same time the enabler of many things, is the ton of global mutable state, that will be very hard to factor out at some point, if ever.
> 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 that vanilla Emacs crashing? Asking because I had such things happening only with Spacemacs in a VM running on a Windows host and blamed Spacemacs.
Crashing Emacs is a rare aberration, GNU/Emacs is incredibly stable, I really don't remember the last time seeing it crash on Linux. On Mac, that could happen, usually due to some .dylib misbehaving, also a rare thing. Don't ask me about Windows, I stopped using it completely and hope to never have to boot into it ever again. Some things in life are just not worth losing your breath over frustration. Anyone who says Windows 11 is not aggravating are out of their mind.
Sometimes, people conflate Emacs crashing and hanging, the latter can happen, but almost never requires killing it - you just send `pkill -SIGUSR2 emacs` from the shell and it unblocks.
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
>When GPT-3 became available, and I did not have to learn Elisp (another f%^&*n computer language - with no other use)
DHH recently said that despite hating Rust, he recently wrote a program he needed in Rust by handing the task to AI, and that the alternative was him having to spend nine months to learn the language.
> 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.
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?
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.
Have you ever considered using any of the tiny clones of Emacs instead? So you'd get the lisp-y experience without the "kitchen sink".
I usually just use Prelude for some modern defaults
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.
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 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.
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
Awesome. I wasn't sure if anyone else remembered those. Formative stuff for me :-)
Probably most of the people who used them a lot at the time would be 55–70-year-old men in the US today. https://www.ssa.gov/oact/STATS/table4c6.html suggests that 88% of US men who would be 55 if they were still alive are in fact still alive, and 72% of US men who would be 70 today if they were still alive are in fact still alive.
So probably three-quarters of the people who remembered them in, say, 01990, still remember them. You remember all those guys, and the occasional gal, you saw at computer stores and user group meetings at the time? Most of them are still alive, and most of them still remember them. They're just harder to find because places like HN have filled up with MBAs.
(I remember ]CATALOG but not *3D0G.)
But when you talk editor names, you should really rather name it "Ed".
Ed is the standard Unix text editor.
And his brothers /bin/bzcat, /bin/pacat, /bin/netcat and /bin/sqfscat.
But does he have a gap buffer?
He is cute though.
So your cat is about to get fired?
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.
Fortunately I only realised that after we’d already registered Cygnus.
"We Make Tree Software Arboreal"
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.
> It's absolutely crazy how it stays relevant for such a long time.
I believe it's because of Lisp. The majority of the new generation of programmers are mostly just clueless about how Lisp remains relevant and how things in the Lisp-world are calmly and quietly getting just built, problems solved, solutions developed - without fanfare and pomposity.
The biggest digital bank in the world uses it. Nubank, using Datomic as their primary tech driver, grew from ~12M customers in 2019 to 131M in 2025 - almost 1000% growth in less than a decade. Not an exactly faithful comparison, but for JPMorgan getting to their ~80M customers took dozens of acquisitions and 150 years.
Netflix uses it. Amazon uses it. Apple uses it. Walmart built their billing system in it. Cisco's entire cybersec stack is on it. Even NASA uses it.
The number of Lisp dialects just this past decade has exploded - you can find practical, working Lisp pretty much for just about any runtime now. The amount of Emacs Lisp on GitHub alone should be at least surprising - you check the GitHub lang stats, and may think how weird - a non-general-purpose PL, that has always had one and only intent, is among some top languages, why? r/emacs subreddit gets daily, pretty much daily announcements of some new Emacs packages. The age of LLMs is now practically proving the value of Lisp. Working with an AI harness through a Lisp REPL is palpably a better experience - agents work faster, spending far fewer tokens.
It is honestly just baffling how almost every PL out there is restrictive, in the sense that they impose seemingly weird and arbitrary nuisances, while Lisp has always had just two necessities - structural editing and REPL-driven workflow. Those are the only two things anyone needs to grok in order to efficiently build with it. And even these are not hard requirements.
It gets frustratingly exhausting to dispel a constant barrage of biases. As if people just don't want to believe their own eyes to see how pragmatically commonsensical it is and always have been.
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.
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!
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
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!
A deeply strange set of choices indeed, including wasting the last few paragraphs talking about Mac OS.
The post 1970s/1980s history of Emacs is one of the more colorful stories in the software development world. The Emacs/XEmacs schism is the most famous episode, but there's also the "waiting for Godot" drama surrounding the Emacs 21->22 release, etc.
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
[dead]
[flagged]
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/
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 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.
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
From the interview with an Emacs enthusiast: "In Jupyter you modify the state of the program. In Emacs, you modify the state of the art." :D
There's also "How to type “blimpy” in Emacs": https://news.ycombinator.com/item?id=37366341
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!
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'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 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 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
As others have said, it's never too late to learn.
My life has been within Emacs for 31 years. Yet I would say that I only really learned Elisp in the past ten years. Still at a tyro level, but enough to write my own functions for VM (I don't think mu4e existed when I started using it, also 31 years ago).
>Anyway, the most important part is: Despite all of this, Emacs is still fantastic for me! Here's to the next 50!
Amen.
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).
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
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.
You're the one complained:
> My Emacs config file is a hodge-podge of little snippets I don't properly understand
People giving you truly time-saving advice. Use a good model to unhodge-podge it. You can even ask it to explain every single Lisp snippet it makes, to the detail and granularity level you prefer - want a big picture, please; would you like nitty-gritty details - ask no more. It's not like it's gonna build a "massive configuration" and absolutely will refuse to make it make sense to you.
Yes. "A hodge-podge of little snippets I don't understand" is the situation I'm in and wish to avoid. "An LLM wrote a lot more that I don't understand" will make the situation a lot worse.
There's indeed lots of good advice in this thread. I appreciate it all! "Just use an LLM for the stuff you don't understand" is, however, not one of them.
You're hypothesizing of something you haven't even tried. What's the worst possible outcome? You end up with more shit you don't understand. You then just throw it away and go back to smaller amount of shit you didn't understand well to begin with.
"Come on just try it" is a quite weak argument.
I'm sorry, but I'm out of magic scrolls to turn someone into a Lisp adept in a blink. So this time you really have to convince yourself to do something about it; I'm powerless against your lazy ass here - the curse is too strong.
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
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.
Can you share a few more details? What did llms help you see that you didn't see before? I myself have tried to get into emacs several times but always went back to vs code as it just felt more natural to me
[dead]
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've been using Emacs since the early 80s, first Gosling's Emacs and shortly after switch to GNU Emacs when it was first released in 1985. In college we had a DEC-10 system and I used Teco on that one.
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.
> someone has made the wrong editor choice
Just the other day I made this comment on the topic of "nvim vs emacs", I think it fits here well:
> editor choice shouldn't be treated like soccer or religion
Oh, I wish there was a choice here. I've been vimming since 2010, the idea of vim modality is an excellent, practical, beautiful model. It's a fantastic idea and the ideas do port. That's why I've used vim-bindings in every editor/IDE/terminal/browser I used.
Emacs, however, is not an editor. It's a Lisp REPL loop with a built-in editor. The only contenders in this space are Light Table, Nightcode, or Lem and none of them truly can compete with Emacs (at least right now), because you can't just ignore forty years of package development. Maybe some more people start using Lem and keep vibe-coding a huge body of Elisp into CL and then maybe we finally see something that can potentially dethrone Emacs.
It's not sports or a religion - you can feverishly love trains and despise airplanes, but you've got to admit, trains just can't replace airplanes, regardless of what you love and believe in.
You’re taking this way too seriously.
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!
TFA begins before GNU Emacs proper, but, still: does age and portability make Elisp the ultimate write-one-run-everywhere language?
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. :)
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.
> By the early 1960s, programmers with interactive computers could use a “line editor” to type their code on teletypes
That's quite a condition ... very few of us had access to interactive computers -- punch cards still ruled for another decade.
When I started using emacs it already felt past well-established and perhaps past its prime. Decades later it feels perhaps more relevant than it did the then. The easier-access defaults kits of the mid-2010s got a lot of new user investment, and it feels like the community really ticked up around COVID. Yes, agentic development has us spending a lot of time in harnesses; relevance-wise, things that aren’t an editor feel more threatening than alternative editors. We’ll see how that lands over time! Most of the reason I use a harness outside Emacs is to take advantage of a Claude subscription.
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.
Epsilon 1982 was very much Emacs, but programmable in C. But it loaded superfast in MSDOS palmtop HP100LX. I made lots of Epsilon programs, which were easy to translate to real Emacs, of the fake Unix, made by Linus.
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.
I don't know how long ago "your early 30's" was, but for me this was never a question - I'm a die-hard vimmer, I use vim bindings everywhere. It's practical, why force myself to relearn my typing with every new tool I use if I really don't have to? Emacs, as it turns out, vims much better than any other concrete vim implementation. Even though I did learn some basic Emacs vanilla bindings, I'm still a vimmer. Vimming in Emacs never was a big obstacle for me.
(not the person you are replying to)
I am primarily an Emacs user, using the standard key bindings (and a whole bunch of custom bindings and functions I've built on top of it over the decades, ctrl remaped to caps lock and no Emacs pinky so far).
But I am also 80% a NeoVim and Vim user for about 15 years now, and I consider myself quite proficient with Vim keybindings. The Emacs emulation is truly incredible, but the fact that Vim implementation quality varies wildly from environment to environment is extremely frustrating to me. For example, the jupyterlab-vim plugin is so jarringly broken in a handful of ways that it completely knocks me out of the flow of whatever I was doing when I encounter those emulation failures. IntelliJ's idea Vim plugin is a pretty decent one, but even there I have encountered the occasional issue [1][2][3]. Otherwise, I strongly agree with your point about learning one way to work with text and being able to leverage it most places.
Sort of a tangent, but I think this is why Emacs users tend to end up trying to do as much in Emacs as possible: It's not really the keybindings but the fact that everything in Emacs is a text buffer. Emacs owns the input and the output, and because everything in Emacs operates on text, you can do most everything in most every mode, to most any buffer content. One example of how powerful this can be is the ability to press a key and use dabbrev-expand to autocomplete shell input I'm typing based off the shell output of a prior command.
1: https://youtrack.jetbrains.com/issue/VIM-569
2: https://youtrack.jetbrains.com/issue/VIM-636
3: https://github.com/JetBrains/ideavim/pull/33
> Vim implementation quality varies wildly from environment to environment is extremely frustrating to me.
I know exactly what you're talking about. I am a die-hard vimmer and used vim plugins in every editor/IDE/browser/shell/multiplexer/WM/etc. I use vim bindings system-wide. I control my music, switch between apps, swap and resize windows - all without lifting a finger from the home-row.
I spent almost a decade living in IntelliJ. I had many direct conversations with Andy Vlasovskikh (he's the maintainer of IdeaVim then). Gary Bernhard (Destroy All Software, wat guy) once said: "there's no vim-mode, there's only Vim" in the sense that no single editor or IDE, not a single vim emulation layer properly works, they all have glaring deficiencies - to the point that it can drive any experienced vimmer truly mad.
With one notable exception. Evil-mode in Emacs is just wonderful. It's the best vim-emulation layer, to a certain degree it works even better than in Vim/Nvim. Weirdest thing - it makes you forget it's not a built-in feature of Emacs. I'm honestly very happy with it, because I don't know, otherwise, I might have never convinced myself to ever give Emacs a try.
These two ideas - vim modality and the grand idea of Lisp - are possibly the two best things that I am forever grateful to my younger self for forcing me to learn. I can't even comprehend being a professional software developer and not grokking them.
I definitely agree with this. Literally the only time I use lisp is when working on my Emacs configuration, but after almost 20 years of using it to write all sorts of functionality from big to small things, just having the exposure to lisp has really helped expand my thinking about programming in ways that working with e.g. C, Python, Rust may not have.
One last thing on the Vim emulation front: While I'm not a big fan of VSCode, the VSCode-Neovim extension[0] connects to an actual Neovim instance via Neovim's MessagePack-RPC API, allowing you to use real Neovim but native in VS Code. Pretty cool!
0: https://github.com/vscode-neovim/vscode-neovim
afaik, even with the extension it only affects the editor pane - any other windows still require tons of mouse use. I'm not mouse-nazi, but years of one-handed use of it have created tons of problems for me - in the neck, wrists and my back. All kinds of mice I tried didn't help - magic trackpad, vertical, ergonomic, etc. I'm sure this is pretty common.
I keep thinking of maybe I should learn to become ambidexter mouse user, and if I ever have to become a VSCoder (I pray not), I still may have to. For now, Emacs and vim and reduced mouse use are working.
True, I lived in viper-mode for quite a while.
I think I bought the Emacs Manual from Richard Stallman in 1979, give or take a year. I still live in Emacs, even writing my own AI coding harness inside Emacs.
I suspect that I am slightly more productive in VSCode for large code bases, but it just makes me feel happier and content to use Emacs.
The best thing that my PhD advisor did was to require me to learn emacs and latex, 32 years ago.
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 :(
What do we call 1970's OS design in 2026?
I have an idea, from someone famous in hacker circles,
"Using Unix is the computing equivalent of listening only to music by David Cassidy"
-- Rob Pike
that's like asking linux to drop posix :D
Source?
What source? It is quite obvious without Proton there are no games for SteamOS.
pretty sure it was meant sarcastically
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
Which means that Stallman is, what, in his early 70s? Which means that I'm... uh-oh...
Somehow I never realized Emacs existed before GNU Emacs. Nice little piece of historical trivia.
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).
> extending Emacs is pain as I never understood the point of lisp
LOL. Skiing is torture as I never understood the point of having to wear boots, since I rather liked sneakers.
Emacs saved my novel. Org mode gave it a home. For that, I’m forever grateful.
It's almost as if you don't like the idea of people reading your novel :) Come on, don't be shy, tell us about it. Is it published?
M-x animate-birthday-present Emacs! RET
recently our company swithed from cursor -> codex. but we only can use the cli or vscode pulgin. with a few hours, i come back to emacs + codex, and ask codex to do a little tweak. everything works perfect.
there is program called 'doctor' in emacs, it's a rules based 'AI', pretty dumb. and it's like 40 years old. 40 years later, people are still using the same editor, just with diffnert AI program.
this is the most elegant and beautiful software i have ever used. and i wish after a 100 years, people will still love it.
I'm slowly getting into it. I only got into vim (neovim) a couple years ago (been computing as a kid since early 80s).
But have been enjoying learning alot of emacs (oh god so much to learn :))
I'm not ready to make the jump (not sure I will jump at all, but...) I am gonna mess with guix in a vm to see how I roll with that.
I've got a lot of digital versions of various books on lisp/scheme but only played with them. Eventually I think it'd be great to do more with slime/sly and sbcl. But for now sticking with the basics. It's a real head trip to see the power of emacs, and it feels like it's hard to explain to people why it's so fascinating (to me).
I have a feeling I picked a good time to hop in, because a lot of the quality of life features seem to have only come in the past few years.
(my experience is specifically to use vanilla and build up from there, to both learn, and to get used to the "proper" way. I was afraid doom or space would end up getting me into their mental models, and didn't want to feel "locked in")
Of course shout out to systemcrafters, joshblais, protesilaos, sacha chua, mickey peterson (and mastering emacs).
God, I haven't even mentioned org-mode or magit (though magit is still a bit rough, I'm used to lazygit - in some ways using magit is making me understand some things about how git operates better).
The other thing is - I feel like I'm walking on unstable ground when using emacs - maybe it's just because I'm learning, and it's so easy to modify, I always feel like I'm about to break something. I know "backup stable config" and reset from that if it breaks, is obvious; but there's a feeling of looseness that comes from it that's a bit intimidating.
I guess I had that feeling with vim at first to. Obviously it's not going to "break" but as a noob, sometimes it's intimidating and feels that way.
The other thing I need to work towards is mastering workspaces/projects (and maybe tab integration) right now I run server/client windowed, no chrome (no tab, title bar). May add tabs for project management, but I wanted to get used to using M-x for things first (and man does vertico, consult, orderless and marginalia help with discovery!) Embark is another big tool I have so much to learn about.
And seeing how people use emacs for publishing. Linkarzu interviewed an author who talked about he used LaTeX for publishing.
One of my favorite facts is telling people that emacs is one of the oldest actively maintained piece of software still at large. It makes me feel like I'm part of an ancient tradition LOL.
Happy Bday Emacs!
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.
Lucky you!
But I've also worked at a different place in the past where - when I asked if I could have Emacs installed on my machine - the sysadmin asked me "What's Emacs?"
¯\_(ツ)_/¯
> 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.
> makes maintenance easier for the sysadmins
Develop hacker's mindset. Don't anyone tell you how to use your computer. Especially don't let your computer to dictate you the rules. Always remain in charge.
When I started at my current job, they gave me a laptop that came installed with crap called ABR - Admin By Request. Basically, for anything that required sudo, they'd force me to run it, then click a prompt: "yes, I need the [fucking] access," then another little prompt comes up, asking for "reasons," and you're supposed to type it, to which everyone on my team types some random number of letters (because there's a minimum), then press Ok to get three-hour access.
I dealt with it for exactly three days. After that I just wrote a script that periodically checks if I have the admin rights, and then waits for me to get idle (so no sudden focus stealing), then runs the sucker, sends the request, etc. I don't even see it anymore - just happens. I'm not playing their stupid games, their "security theater", I have a job to do.
> Develop hacker's mindset. Don't anyone tell you how to use your computer. Especially don't let your computer to dictate you the rules. Always remain in charge.
That would be nice in theory. I've worked in many different places throughout my career and in almost all of them, the sysadmins had the final say in what software was okay to install on your machine and which one wasn't.... because "security".
> That would be nice in theory.
I just gave you an actual, practical example, not a theoretical one.
Here's another one. I wanted to try eca-emacs, the documentation website sits at https://eca.dev, Cisco Umbrella, for whatever stupid reason, blocks the entire .dev domain, and every corporate laptop comes pre-installed with Cisco Secure Client that you can't remove. I submitted a ticket, and then wasted my time on a ridiculous exchange with the "big security guy," who decided to take a power trip and refused to have the website whitelisted. Despite it being absolutely harmless. I don't know where the fuck he's purchased that condescending tone and posture. In the end, I said: "thank you for your time," and hoped to never ever have to talk to him. Then I set up a SOCKS tunnel through my local Linux box, installed the FoxyProxy extension, and voila - I'm never ever going to have to complain about a blocked website.
> sysadmins had the final say
And you can always find workarounds. Those who want to do something look for a way, not excuses. You're a goddamn computer programmer. Maybe act like one.
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.
[dead]
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.
[flagged]
[dead]
[dead]
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.
Very interesting. I was very active on Freenode#Emacs. The Emacswiki and all of those resources. I jumped onto and heavily got into org when I first came across it in the early 2010s I think.
But you're right, it looks like Emacs went on strongly but I fell off the bandwagon.
libera#emacs tends to have around 8-900 users connected (maybe more when the US is awake, probably not everyone uses a bouncer). Both reddit and mailing list are quite active too.