Quote from the bottom: “To keep up with decreasing computer memory capacity and disk space, many other functions and files have been eliminated in Emacs 30.2.”

Honesty, not such a wild proposition in 2026 with new hardware generations offering the same or less RAM and storage!

There’s some great stuff in there.

> 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.

I always assumed it was a bit of a common practice from image based development practices. I'm now assuming I was incorrect on that being the case?

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.

There was a lot of discussion around the time it was being removed[0], but it seems the glibc people simply didn't want the support burden and Emacs was the single user of that interface. I think the issues could have been resolved by checking if all shared libraries are exactly the same as when unexec was called, that the kernel is the same and that the CPU is the same, and failing if anything doesn't match, thus falling back on slow startup. That said, portably serialising the state and loading it back is a better solution IMO.

[0] https://lwn.net/Articles/673724/

GNU Emacs isn't the first Emacs, although it's still an impressively long-lived and vivacious one.

AI is very good at Emacs Lisp - esp GPT. So you'll have an easier time around today!

Are there any Zed features you're going to miss? Is the AI notable?

I infer you don't use magic?

You don't have to just "stare" at the source; you can interact with it! Emacs is incredibly well documented and you can learn a ton with just C-h f (i.e. M-x describe-function) and C-h v (i.e. M-x describe-variable). In an Elisp source file, use those commands whenever you don't know exactly what a function or variable does. Read the description, and click on the hyperlinks to see the source. This is IMHO the best way to learn how to actually get things done. If you don't know what function or variable you're looking for, M-x apropos and its variants will be helpful.

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.

> does anyone have good learning materials on doing things with Emacs Lisp

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.

All of Prot's packages[1] are really nicely designed imho.

[1]: https://protesilaos.com/emacs/

Have you read through the Emacs Lisp Intro and Elisp manuals in Info? The latter is especially helpful as a reference.

I started getting a little more into ELisp after reading The Land of Lisp, though its probably a bit basic. If I were to try to get better at ELisp through reading books/docs, I'd look into Common Lisp material.

Unfortunately the NS/macOS version still needs work as far as I can tell. Even not fully featured it's still useful: I prefer reading PDF in xwidget-webkit than pdf-tools, and it's great to have Jupyter notebooks running inside a browser inside Emacs.

I recommend the tutorial (Help -> Tutorial) from the menu bar inside Emacs to get you started. Don't listen to people telling you to disable this or that. Use your mouse and arrow keys to get started. Don't worry about what other people are doing with their Emacs too much. Pick one thing you want to do with Emacs and focus purely on that (writing Go, taking notes in Org, etc.) and avoid a wholesale move unless you have infinite time and patience.

See also my reading guide: https://www.masteringemacs.org/reading-guide

My book is of course an option also, but it costs money.

It's no different from learning vim. Just stick with it until the shortcuts become cognitively automatic.

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.

Start with Doom Emacs. I haven't felt the need to customize almost anything since I switched (from VSCode) 4 years ago.

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...

Mastering Emacs: worth every cent. (ignore what author says about it costing money) It is what got Emacs to “stick” for me.

Just get it already

I'm in the minority and think the tutorial is awful. "Here's this software everyone says is so great. Before you can actually use it, be sure to spend 20 minutes doing a bunch of stuff for which you don't have context/don't have motivation for"

No thanks.

Instead, literally just start using it and ask an LLM for help as you go.

Emacs is incredibly powerful with ai agents. Because everything is a function, and emacs is introspectable down to its atoms - agents can write, review, execute, and evaluate the results in a closed loop. The evaluation part is usually what's missing from most agent-driven workflows. Either you (the person) needs to do a live evaluation or the ai agent derives a primitive evaluation using what's available (eg, screenshots, looking at html/css output to form a visual representation).

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.

You should give https://github.com/xenodium/agent-shell and https://github.com/dakra/ghostel a shot. With ghostel I genuinely mix up which window (frame) is emacs rather than the native Ghostty window.

That's funny, because our professor didn't tell us that and I remember doing my projects with four terminal windows logged into the server and three of them running separate instances of emacs :D. I wonder how much I bogged down that mid-90s HP-UX machine.

I thought the same, but later on in the article they go into more details and explain that lisp files under that directory will be auto loaded and commands they add should just work! Really good stuff.

In fact, the author of this blog post is also the author of a book on Emacs, which includes a section about Vi(m) bindings and migrating from Vim: https://www.masteringemacs.org/article/switching-from-vim-to...

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.)

We should be so lucky. No, sadly, bruv has repeatedly enticed handing over the keys over a silly dustup like the portable dumper, the long line mishandling, or the c-ts-mode incident where he could not bring himself to admit wrongdoing, then invariably back out hoping no one will remember his tantrum. This emacs thing is really all he has.

He's in the MAINTAINERS file[0], and the person with the most commits in 2016-2026 period, so no.

[0] https://github.com/emacs-mirror/emacs/blob/master/admin/MAIN...

The pdumper has been around for yonks, and afaik Zaretskii is still maintaining.

The post mentioned so many things and went into lots of interesting discussions about the new stuff . I find it amusing you think it’s ok to criticize the author for not trying things out and not mentioning your favorite topics. Here’s an idea: write a better post yourself.

But I do test things out, by virtue of often running the tip of master branch and submitting bug reports. But I cannot test every mention in the NEWS, so on that part you are right.

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.

temacs, in older versions of Emacs, is an intermediate build product, never something that is installed. It’s created fairly late during the build, then loaded up with the standard library, undumped, and that is the emacs that is installed.

You typically won't see it installed at all because it's considered an intermediate artefact. You'll have to compile Emacs yourself from source to get it.

Well for what it is worth, I build Emacs 31.1 on Slackware 15.0 and it has an odd issue. I get this message below but issuing that command does not fix it, the warning still appears. So either I need to move from ccrypt to a different encryption utility or revert. For now I will revert and decide if I want to use gnupg instead. I use ccrypt for my password list text file.

    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 :)

My Combobulate page has suggested package versions but note I have not yet confirmed 100% compatibility with every single Emacs 31.1 major mode yet, though all tests for Combobulate do pass in 31

github.com/mickeynp/combobulate

Have also struggled with this- would be great to see a fix

i just gived it a try. works like a charm, treesitter + lsp. i asked cursor to help me with the config.