What's new in Emacs 31.1
masteringemacs.org
masteringemacs.org
> As part of our continuous struggle to make Emacs simpler, we’ve removed the `margin` face, so text shown in display margins will now use the same `default` face as the rest of buffer text. Our long-term goal is to remove faces completely, thus leaving the Emacs with just two colors, so we gradually remove more and more faces as we go.
Honesty, not such a wild proposition in 2026 with new hardware generations offering the same or less RAM and storage!
As to AI: Emacs continues to have zero built in. If you like it, though, it supports any agent you might want to use. I was highly amused the first time I wanted to use my own company’s agent and found it was already well-supported by a popular package.
And honestly, Emacs + a coding agent = magic for anyone who wanted to use it but was intimidated by Elisp. “Hey Droid, tell Emacs to swap the command and option keys on my Mac.” “Ok, done!” It’s a ludicrously powerful combo.
I can tell you why working in Emacs feels empowering - when I'm working with an LLM, my Jira tickets are "transparent" - Emacs knows that any pattern that looks like 'XYZ-124354' is a Jira ticket - I can check the status, description, and other things on the fly. I don't need to switch to any other tool, need no browsing of the ticket. I can quickly convert it to a markdown link with a description (if I need to talk to my colleague about it). Same thing about 'foo/bar#42' pattern - Emacs recognizes it as a bug-reference token - it's an issue or a PR - I can immediately retrieve any info about it in the middle of typing.
I can collapse any large parts of my investigation without affecting my context and I can peek into them without expanding if I don't have to. I can change my freshly typed prompt using a different model, with different parameters, asking it I don't know, fact-check my assumptions or fill the gaps - all that while I'm typing it in my coding AI assistant buffer.
I can search for and pick a Slack thread interactively, without having to even switch to Slack, and tell the LLM to look into it, or simply extract some text or a snippet to paste it verbatim, or with modifications.
I can interactively pick a tab in my browser and insert its url, or grab a text from it. Without ever switching to the browser - it could even be not visible on my screen. I similarly can grab anything from my browser history.
Moreover, I can ask an LLM to change any aspect of my editor on the fly. If there's a use case I stumble on, I'd just slop the shit out of it and watch the agent drive my active Emacs instance, trying different things, popping up windows, taking screenshots and comparing results. I can name countless real, practical, everyday examples where I changed my workflow without missing a beat - some are trivial and some are more complex, and Emacs delivered. Without a hitch or a restart.
Emacs remains the absolute king for text manipulation of all kinds and text in the age of LLMs is simply everything. Nothing can beat Emacs when it comes to text, and oh boy have I tried so many other things.
Emacs has 35+ different AI tools.
https://www.reddit.com/r/emacs/comments/1uwm3c0/the_state_of...
Not being built-in into the core, means nothing. Emacs just doesn't operate that way.
I don't think that Emacs ships with any AI agent support today, and that makes some people happy, so I mentioned it. Note that I also mentioned that there are packages that do add that support, and I happily use them.
Way more than that if you count all the unpublished homebrew balls of glue.
I've been playing with writing my own lately. I just wrote a cool (IMHO) macro for defining tools, a defun-like form that at once generates both a callable Elisp function, and all the RPC pageantry needed for AI to call that function. From the same syntactic form.
The first tool I wrote was a function for retrieving source definitions of Elisp functions. Just enough to bootstrap the LLM harness into studying its own source code, reading one function's source and requesting new functions in turn, following the callgraph. It's neat to watch. It can dive into Emacs' internals too, since those are Elisp also.
It's a fun project.
Obviously, only a Mac user would need to do that. Every other person will just do this customization the normal way.
Working with LLMs in Emacs is pure joy. LLMs are all about text and Emacs is the absolute king here. Nothing, even remotely comes close. Emacs is not a text editor - it's a text orchestrator, you can control any text-relevant aspect in its computational vicinity - anything you see on your screen, local and remote computers.
Anything else might feel great for coding, but what do you when you need etymology or definition lookup, thesaurus exploration or translation in the middle of typing a comment? Well, you might say: "I'd bring the browser", but that's the equivalent of keeping your cup in the kitchen and whenever you need a sip of coffee, having to walk over there and back to your home office.
I can start conversing with a model virtually anytime, anywhere in Emacs. I can ask it to find me a command while I'm browsing the M-x menu, can you do that in Zed's command palette?
I can send a query asking for... I dunno, to fact check a sentence in the middle of typing it. While working with a model in ECA (Editor Coding Assistant) on some codebase, I can ask gptel (unrelated package) to correct my own prompt, using a different model, with dissimilar parameters. Or ask it to find me a way to summarize my current investigation, or combine multiple chats into a single pdf document, etc. The only limitation is your own imagination.
BTW, I’ve been using Emacs for like 30 years. I’m comfy with it. The bankruptcy is more about throwing out an old config that’s gotten big and crufty and restarting doing things the new way. For example, trying all the new completion stuff instead of corfu/vertico/etc., which are supremely nice but perhaps no longer essential. Similarly, a few years ago I went from lsp-mode to eglot, because it’s built in and a nice baseline.
fittingly so but still annoying. srry
only now I realize I misread your comment as saying "besides tree sitter and eglot there is not much in emacs"
and somehow that is not what you said.
is this what you meant: "Now that modern IDE features (syntax parsing and LSP support) are built into Emacs out of the box, I don't feel like I'm missing out on modern editors like Zed. I’m ditching my bloated, outdated Emacs configuration file and starting fresh with a clean, lightweight setup that relies on standard built-in tools."
?
then apologies for my confusion.
More tersely, since adding LSP and treesitter, Emacs has every cool feature I want from every other editor out there.
And yes. I’d slowly evolved my config over years, starting with ancient settings and gradually adding layers of tweaks on top of them. I’m starting over with a new config, using the built-in features whenever possible, and tweaking those into the modern equivalent of what I had before.
By analogy: I’m upgrading from a hand-maintained Debian 7 install and switching to the new apps in Debian 14 when I can.
There are projects that seek to do just that. I'd recommend taking a look at them to get an idea of whats possible with an almost-entirely-vanilla emacs setup.
Examples:
https://codeberg.org/ashton314/emacs-bedrock
https://github.com/LionyxML/emacs-soloAlso available in video form on YouTube.
I think he's a great resource for coming to modern emacs.
I have the Mastering Emacs book and read through most of it, which gives me a good idea for some stuff... but I really would like to have good ideas for the right kind of design patterns for common things.
I don't have a good reference (other than the Elisp manual) for high-level design patterns, but in general, Elisp is very flexible and already has what you'd need to implement any patterns you know from elsewhere. Decide on your data structures first. Probably the most important lesson you might not know yet is to use buffers, not strings, to do most text manipulation.
Pick a quality model, even good local ones are fine, you don't need to feed greedy capitalistic machine. Talk to it. Your first step would be to find a way for the model to "peak into" and change actively running Emacs instance - that's typically done through emacsclient.
Next step - choose a harness package - ECA, gptel, agent-shell, etc., with the goal of running the AI from inside Emacs. You can use external tools - pi, claude, copilot-cli, etc. to get there.
And then just ask questions. With utmost curiosity. Like: "What is lexical binding", "why did you write it this way", "how pattern matching is done in Elisp", "how do I make this type of window to always appear on the right", etc.
Best way of learning is by building something practical. In your case, you'd be building your own Emacs. Just the way you imagine it. And that's virtually the only limitation to it - your own imagination.
Protesilaos has a book on this topic. Might be what you are looking for.
I'd love to read a good history of the different development styles. I know we often have a good exploration of the parts of an executable file. I don't recall seeing a good exploration of different compilation/build styles through the years.
Mostly I've noticed unusual compilation/build styles when they come into conflict with version control systems. One weird one was when I was contracting 01996 to 01997 at TCSI, Teknekron Communication Systems, Incorporated, which I guess was a spinoff of Teknekron dedicated to building telco software. I was working on a project called STNMS, the SONET Tunnel Network Management System. There were some pretty funny things about the project, including some amazing recursive acronym soup. One of the major components of STNMS was the NGEMS TOM, which stood or NGDLC Element Management System TCSI Object Manager, or, fully expanded, New Generation Digital Loop Carrier Element Management System Teknekron Communication Systems, Incorporated, Object Manager.
Anyway, one of the interesting things about the system was that it was built on a distributed object system like CORBA or PARC's ILU or DCOM or eventually Java RMI, where you would invoke methods on objects, and the methods could execute in another process or even on another machine. So the NGEMS GUI would invoke methods on NGEMS-related objects which were actually implemented by code running in the NGEMS TOM, which might be on another machine, so that you could be running the NGEMS GUI on lots of machines, all calling methods on the same NGEMS-related objects, which could therefore avoid any concurrency-related bugs, I guess.
I'm not totally sold on this actually being a good idea, among other things, because the various TOMs stored their data in an INFORMIX-ONLINE SQL database server, which had pretty decent concurrency control already, and was pretty fast.
I was responsible for maintaining the bug-tracking system, the INFORMIX servers in the test environment, the build system, and the software version-tracking system, which was a pile of csh scripts built on top of RCS, running on NFS. And I was also responsible for doing a full system build, I think about once a month, which usually took me about a week of tweaking things. I was 19, and it was 01996, so I didn't know any better. I'd learned SQL and RCS by reading the O'Reilly books on the plane out to California.
Anyway, TCSI wasn't using a CORBA ORB or an ILU ORB or a DCOM ORB for their RPC layer. They'd written their own ORB, whose name I forget, but its IDL was generally called "MOSU", and lived in files with the .mosu extension. This stood for Methods, Objects, and something or other I can't remember; just as with any ORB IDL, you needed to define the class interfaces and methods and parameters that you could invoke through the ORB, so that the clients and servers would agree on what they were. You'll have to forgive me for the vagueness — it's been almost 30 years, and even at the time I wasn't writing code that went into the system, just tweaking it until it compiled so the 30 or so programmers and testers on the project could get on with their work.
The thing that caused trouble with version control was the .moslog file that accompanied the .mosu file, assigning numbers to methods and objects.
For efficiency, there was a small positive integer assigned to each of the methods, objects, etc., that the ORB's protocol could refer to. The client and server also had to agree on these numbers, just as in Protocol Buffers you need a unique tag number for each field that all users of the .proto agree on. You could solve this by burdening programmers with the need to declare these numbers in their IDL (the .mosu), as protobuf does; or you could solve it by reaching agreement on them when the connection was opened and then doing the mapping dynamically during the session, as X-Windows's XInternAtoms() does; but the MOSU IDL compiler solved it by assigning these MOS numbers automatically, starting with the smallest natural numbers.
But, to ensure that it assigned them consistently, it would log the assignments to the .moslog file.
Therefore, the .moslog file had to be checked in to source control, but the build process might modify it. And, if different programmers added things to the same .mosu, their .moslog changes were almost certain to conflict, because the compiler would assign the same next number to both things — conflicts I seem to recall I sometimes had to clean up by hand. Of course this required sneaking around behind the back of the version-tracking system, since RCS requires exclusive locks to modify a file, but often the programmers did have to sneak around thus in order to get their work done, for example because someone else had the .mosu and the .moslog locked that day.
TCSI is now dead and gone; https://en.wikipedia.org/wiki/Teknekron_Corporation tells me that it was bought by Rocket Software in 02003. I think the STNMS project failed, and BellSouth, the company that was paying TCSI to build it, also no longer exists. So, I doubt anybody has used these primitive tools in 20+ years, and I haven't seen them described anywhere publicly before, perhaps because TCSI foolishly thought they were a competitive advantage at the time. (I hope I haven't made too many errors in my recollections.) But it's interesting what we can learn from them for the future.
Today, there's a somewhat similar thing that happens with generative testing systems like Hypothesis: when they find a failing "instance" of a property-based test, they record it in a database of failing tests, so that you can always use it in the future. So the "build process", or rather the test process, sometimes produces data that must be checked in to the version tracking system. This doesn't mesh well with conventional version-control workflows, and especially established continuous-integration systems which blow away the universe when the test suite finishes running.
Of course, training AI neural networks doesn't fit cleanly into the conventional version-control model either.
See also my reading guide: https://www.masteringemacs.org/reading-guide
My book is of course an option also, but it costs money.
Just get it already
Folks in the modern age, who want to get up to speed with an old trusty tool, without the biases of other folk getting in the way.
You get up to speed enough, that you can then go find your own way.
Mickey’s writing is conversational yet pithy and laconic. (in a very good way)
TBH, I had used Emacs before VSCode and had accumulated a bunch of cruft in my .emacs configuration, and I never felt it was "mine" anyway...
It also helps to learn upfront the idiosyncratic terms and concepts like buffers, windows, frames, yanking, killing, etc.
Most of these terms map one-to-one to more familiar nomenclature like copy, paste, etc.
Buffers is a concept a bit more unique and integral to emacs. It's easier to understand in practice than in reading.
Most importantly though, emacs is a lisp machine, and exposes the highest level of granularity, and enables the finest level of customization for the user.
No thanks.
Instead, literally just start using it and ask an LLM for help as you go.
The maybe complementary, or at least deterministic source of advice is old school 'M-x info'.
Eventually, Mastering Emacs will be free!
Then I am going to try to learn more of the navigation keys (I got some of the basics (mostly)) but still need more experience beyond the basics. I am able to get my odin/raylib code to compile with C-c C-c. I even hand compiled 30.1 from github to update from Debians older defaults. The only problem I ran into was forgetting how I got it so when I launched the client it didn't duplicate the icon on my kde taskbar/panel. Uninstalling the old setup must have removed my copy of the start up rules/desktop window name. But got that settled after a bit of searching.
I am trying my hardest not to use EVIL, but it's so tempting, because I've gotten used to modal. But I want to use the full power as mostly established with the key combos.
I'm not sure how much of these features will matter to me as I'm not sure I've used much of the full system. Anything that makes it faster is nice. So far it's been smooth, but I do wonder if running the server (via sysvinit in mx) does cause some lag, as I've felt the system have little hiccups (not when using emacs actively, the client not even open. I did try to adjust the GC settings I found as a tip to reduce lag and do more GC when not heavily used).
Finally does anyone know where to get a 'Meta' 1.25u mechanical keycap???
Even "spacecadet" themed caps I've seen still use "Alt" as the title. Anybody have thoughts on like colemak-dh vs qwerty or other layouts. I think it was protesilaus saying he liked chocofi with colemak-dh (and very insistent that it was "THE" way) so I'm curious if anyone had experience with that (or maybe it was another emacs user).
That's been both a good and a bad in that on the one hand, I didn't have to relearn every key, but on the other, especially because I swap between middlemak on the external keyboard and qwerty on the built-ins I'm sometimes mistyping because the qwerty key is one key over from where the middlemak version is. But at least for how my brain works, having that familiarity made sticking with the learning curve a lot easier.
I also can't speak for how it feels on a "normal" staggered keyboard since I only use it on the ergodox but I don't have a reason to think it would feel worse. If it helps, this is the keymap I use on the ergodox[2].
[1]: https://www.reddit.com/r/Middlemak/ [2]: https://configure.zsa.io/ergodox-ez-st/layouts/wzKWq/latest/...
Since then, friendly AI emacsers stuffed usable versions of graphical browsers into emacs, but those never felt truly emacs-native and did leave quite a bit to be desired (embr, the least unusable of the pack, being referred to here; among its warts - unreliable link detection; forcing “tabs” within a buffer; non deterministic unresponsiveness; causing C-g to lag).
Finally I can rid myself of such impurities from core emacs!
Feels monumental to see that come to an end decades later.
None of that has anything to with emacs vs vi -- the point that your professor was making was that vi was distributed by default with UNIX so it was always there, whereas emacs needed to be installed (which wasn't even an option on servers).
TFA's wording on that is a bit misleading.
My Emacs with no config starts in 0.1s (110 ms). My Emacs with my huge config (between 3 000 to 4 000 lines of custom Elisp code) starts in 1.2s or so.
And then of course modern day Emacs is so stable that the thing can stay up for weeks without needing a restart.
It's been a very long time that the "cost of firing up Emacs" is smaller than the cost of firing up 99% of all the software out there (looking at you AppImage , flatpaks, browsers, any desktop app really, etc.).
Stock Emacs: 110ms (Debian Trixie / AMD 7700X / WD-SN850X SSD).
Boom.
By installing the grammars on the user's behalf, I think I might be in luck!
I don't remember the exact issue, but I remember having to dig through the release histories of each of the poorly documented ABI version for each language to find whichever versions was compatible.
I've got my fingers crossed.
github.com/mickeynp/combobulate
Tree-sitter grammar for `go' is missing; install it? y
Cloning repository
Compiling library
Library installed to /Users/xxx/.emacs.d/tree-sitter/libtree-sitter-go.dylib
looks pretty good.
I hope to upgrade to 31.1 on Slackware either today or tomorrow. I will grab the source from Slackware current and compile/install :)
for more information.
* Warning (files): Missing ‘lexical-binding’ cookie in
"/usr/share/emacs/site-lisp/ps-ccrypt.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.
But Emacs 31.1 is in Slackware Current, so when Slackware is released I will be on it :)
In emacs, everything is available, everything is a primitive function, everything can be inspected, the documentation (ie, contextual food for agents) is built-in, and emacs itself can be piloted entirely through function calls. This means that agents can fully control an emacs instance and run that closed loop (write, test, evaluate, repeat) with almost complete information - which makes the [given prompt] : [results conforming to spec] relationship much tighter than in most environments.
dired mode is fine, and i appreciate it, but having the folder view docked on the left, was something i missed in emacs, happy its finally here
Regarding :vc and :load-path, this was obsoleted transitively due to the obsoleting of package-vc-install-from-checkout, which has portability issues. Bug#80604 goes into the background for this. This is NOT an obsoletion of the :vc keyword for use-package.
Regarding package-autosuggest, this is disabled because it doesn't interest most users. It is targeted at new users who aren't familiar with the packages, and might be interested in new major modes. Experienced users are generally either familiar with the packages and use them or prefer to stay in fundamental mode. The minor mode is enabled as part of the newcomers theme!
No mention of package-review-policy, which especially in the "age of AI" is an important feature is you want to be careful about external code you are using on your system.
Oh and on the topic of the newercomers theme, the reason it is not mentioned "higher up" in the NEWS file, besides it being the wrong section, is that it is highlighted on the splash screen, where new users are going to find it, instead of a NEWS file.
Deprecating :vc + :load-path without expressing why is a curious oversight. And "portability issues" is all fine and good, but why embed custom git clone + build grammar code in the treesit.el file if VC checkout portability is a concern? Surely VC is better at it than a bunch of brittle string concat code in treesit.el I do not understand why one part works and another supposedly does not.
The change is especially infuriating as for most of us it actually worked fine, and user-lisp directory does not solve the retrieval and setup problem, which `use-package` for all its flaws at least standardises.
Most users probably do care about discoverability of related packages, existing user or not. But that's in the eye of the beholder.
`package-review-policy` is security kabuki theatre. Someone who wants to harm an Emacs user can find many other ways of doing so with or without this flag.
This is the kind of research that I would expect an article like yours to make. It is totally fair to contact the people who worked on this, instead of being smug about it and caricaturing the Emacs maintainers as conservative.
[0] https://github.com/emacs-mirror/emacs/blob/master/admin/MAIN...
Bruv would run the same guilt trip maybe once every couple years, the last time being the c-ts-mode snafu of his own creation. That time, someone snarkily replied, "Please do [resign]!" Bruv hasn't done it again since. This emacs thing is all he has.
And Emacs is strictly more powerful than Vim. :)
(I mean that seriously, actually— I don't think people who have used both but prefer Vim would generally list "more powerful" among their reasons for preferring Vim. It's usually more about not liking Lisp, some kind of "minimalism", or a different sensibility about composability.)
However, the years of muscle-memory might be deceiving. Vim's objects are text-shaped - the design has no idea of what a function or an expression is. Vim's grammar is excellent but its nouns are approximations. The modern answer perhaps to keep the grammar and upgrade the nouns, which is what tree-sitter text objects attempt of doing.
Anyway, my main point is not about the grammar, but about the grand idea. The idea of Vim is a beautiful, pragmatic model and it can be perfectly used outside of Neovim. If you truly want to take it to another level, maybe consider combining it with the power of Emacs.
Innovation and insight rarely happen within a single substrate - you typically need to explore intersections of divergent disciplines. Emacs itself is rooted in another grand idea, arguably one of the most important ideas in all the history of computer science - a practical notation for lambda calculus widely known as "Lisp". Once you understand the immense, pragmatic value of that idea, it eliminates any skepticism you might have held against it.
If you think Emacsians don't get vim, well, you're misinformed. There are thousands of vimmers who choose to be viming in Emacs. Because Emacs vims better. As a die-hard vimmer I can attest.