Between treesitter and eglot (read: LSP), there’s not much from other editors I miss when using Emacs. I’ve been on a Zed kick for a while but I hear the call of the GNU. This may be the week I declare .emacs bankruptcy and start again with a clean setup, seeing how much of my old third-party config I can replace with builtins.
wmedrano · 2026-08-25 04:18:51 UTC
Are there any Zed features you're going to miss? Is the AI notable?
kstrauser · 2026-08-25 05:00:24 UTC
Not really, no. Zed’s a fine editor and I have nothing but good to say about it. I just happen to prefer Emacs more. Its keystrokes are burned into my muscle memory. And because its config files are literally executable code, there’s nothing too crazy for Emacs. Can it do XYZ? Absolutely, if you tell it to!
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.
ubercore · 2026-08-25 09:09:58 UTC
I went full circle on AI. For an in-editor experience, Zed is top notch. But I've found I actually prefer just to go back to claude code + Zed.
iLemming · 2026-08-25 17:07:36 UTC
Personal opinions. How is it "top-notch", what does that even mean in practice?
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.
LeBit · 2026-08-25 13:17:36 UTC
And if the correct keystrokes are burned into your muscle memory, you can opt for Evil mode.
Not being built-in into the core, means nothing. Emacs just doesn't operate that way.
kstrauser · 2026-08-25 16:26:29 UTC
That's correct. But most of the time when I see that question lately, it's because people want to be sure the editor doesn't have "built-in AI", whatever that might happen to mean. For example, I've seen lots of comments like "I like Zed but wish there was a version with no AI support in it whatsoever". I don't share that opinion. It's one I've seen many times.
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.
peri-cl · 2026-08-25 18:14:32 UTC
> "Emacs has 35+ different AI tools."
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.
tapete1 · 2026-08-27 06:45:48 UTC
> “Hey Droid, tell Emacs to swap the command and option keys on my Mac.”
Obviously, only a Mac user would need to do that. Every other person will just do this customization the normal way.
iLemming · 2026-08-25 16:03:01 UTC
> Is the AI notable?
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.
mickeyp · 2026-08-25 06:33:30 UTC
AI is very good at Emacs Lisp - esp GPT. So you'll have an easier time around today!
thom · 2026-08-25 11:23:26 UTC
Yeah, I've always had the problem in Emacs that I know some quality of life feature would be possible to implement, but it'd take me hours or days so I just end up going back to work. With gptel, I've been able to really take control of my environment. And what's great is the LLM can write better LLM-integration functions too so you really end up with the perfect harness for whatever you're doing.
kstrauser · 2026-08-25 14:13:38 UTC
It really is! For anyone who’d wanted to try Emacs but found it overwhelming, AI is game changing.
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.
zelphirkalt · 2026-08-25 17:23:19 UTC
I also tried lsp-mode first but then thought "Let's see what the built-in has to offer, if that's simpler." and am sticking with eglot since then. It does enough for me, and the configuration is manageable.
kstrauser · 2026-08-25 17:34:48 UTC
Same. lsp-mode's quite nice, to be sure, but eglot's also excellent and it's been completely sufficient for my needs.
froh · 2026-08-25 09:52:33 UTC
I infer you don't use magic?
imglorp · 2026-08-25 10:36:57 UTC
You mean magit?
alfiedotwtf · 2026-08-25 12:49:19 UTC
After realising you can modify the transient menus pretty easily, magit has been even more wonderful now
aquariusDue · 2026-08-25 17:22:20 UTC
Wait, what? Do tell more, please!
alfiedotwtf · 2026-08-26 12:21:34 UTC
When viewing a transient menu, C-x l
froh · 2026-08-26 10:58:11 UTC
yes. autocorrect and the wrong glasses turn magit into magic
fittingly so but still annoying. srry
kstrauser · 2026-08-25 14:18:03 UTC
Why would you infer that? Magit’s great!
froh · 2026-08-26 19:50:13 UTC
oh.
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.
kstrauser · 2026-08-27 14:13:00 UTC
Ohhh, got it. Yes, correct. I’ve used Emacs for ages. Some newer editors came along with more powerful language features that I’d wished Emacs had. Now that the editor ecosystem is converging on LSP and treesitter, and Emacs supports those well, it now has identical capabilities to those other editors. Now there’s nothing the others can do that Emacs can’t, or at least nothing I really care about.
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.
tom_alexander · 2026-08-25 22:28:33 UTC
> seeing how much of my old third-party config I can replace with builtins
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.
Those are both fantastic starting points. I wanted to get even more barebones, though, just for the experience of building it up myself from scratch. The options you mention are a far more practical approach than this. I’m just not feeling entirely practical this week.
greggyb · 2026-08-27 12:06:08 UTC
Protesilaos Stavros has a lot of good content on Emacs and does nice deep dives on configuring both built-in and package-provided features.
I think he's a great resource for coming to modern emacs.
pkal · 2026-08-24 17:25:12 UTC
I was annoyed by some of the comments in the "Packages" section, because it is clear that the author didn't try anything out but just scattered a few comments though out the file.
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.
mickeyp · 2026-08-25 06:24:30 UTC
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.
pkal · 2026-08-25 21:31:24 UTC
The portability issues of `package-vc-install-from-checkout' are due to issues with symlinks not being portable, which is what that function relied on. None of this is related to tree-sitter. That is the function that the combination of :vc and :load-path would use, which just had to be transitively deprecated due to the mistake in `package-vc-install-from-checkout'. Critically `package-vc-install-from-checkout' _does not_ do any retrieval, the checkout of the package had to already exist beforehand, which use-package did not take care of. The function just made sure that package.el would activate the linked directory. User Lisp provides this same functionality. Do not confuse it with the :vc keyword that invokes `package-vc-install', which actually retrieves a checkout of some repository and prepares to do be loaded by package.el.
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.
brabel · 2026-08-25 06:55:02 UTC
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.
pkal · 2026-08-25 21:17:23 UTC
That is what https://www.emacswiki.org/emacs/EmacsThirtyOneHighlights is for. And it is not so much that the author doesn't mention the topics, but that he misconstrues them or just plain doesn't appear to understand what he is talking about.
wmedrano · 2026-08-24 21:14:55 UTC
I'm excited for the user-lisp/ changes. It'll let me create custom lightweight packages and have them lazily loaded by just sprinkling ;;;###autoload over interactive commands and modes.
rtpg · 2026-08-24 23:31:28 UTC
Bit of a tangent but does anyone have good learning materials on doing things with Emacs Lisp beyond just staring at the source of packages?
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.
MarsIronPI · 2026-08-25 00:49:38 UTC
Have you read through the Emacs Lisp Intro and Elisp manuals in Info? The latter is especially helpful as a reference.
wmedrano · 2026-08-25 01:05:27 UTC
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.
rootnod3 · 2026-08-25 04:55:45 UTC
All of Prot's packages[1] are really nicely designed imho.
He’s also got a Youtube channel if you prefer to learn that way.
rootnod3 · 2026-08-25 06:32:34 UTC
And coachings!
rwl · 2026-08-25 11:17:12 UTC
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.
iLemming · 2026-08-25 17:18:08 UTC
> 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.
The pdumper has been around for yonks, and afaik Zaretskii is still maintaining.
jake_and_fatman · 2026-08-25 16:34:55 UTC
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.
quotemstr · 2026-08-25 20:27:41 UTC
Why would he resign over that? He's threatened to resign over removing DOS support, but has no problem with pdumper.
jake_and_fatman · 2026-08-25 22:34:17 UTC
I'm not going to argue. If enough people think I'm mistaken and want
to go the portable dumper way, I will resign right here and now. It
is very easy to convince me to step down, because I hesitated to take
this job to begin with. -- lists.gnu.org/archive/html/emacs-devel/2016-11/msg00640.html
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.
quotemstr · 2026-08-26 01:39:16 UTC
Oh. Correction noted. That's all water under the bridge now though. You can't hold grudges forever.
hirvi74 · 2026-08-25 04:46:38 UTC
I hope my Treesitter issue has been fixed with macOS. I gave up on the problem about this time last year.
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.
mickeyp · 2026-08-25 06:34:48 UTC
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
fergie · 2026-08-25 07:49:25 UTC
Have also struggled with this- would be great to see a fix
yanhangyhy · 2026-08-25 09:51:25 UTC
i just gived it a try. works like a charm, treesitter + lsp. i asked cursor to help me with the config.
hirvi74 · 2026-08-25 15:44:05 UTC
Omg, I can finally return to my beloved for all the languages I use. Thank you for the update.
yanhangyhy · 2026-08-26 02:32:14 UTC
glad it helps. but i dont know much about treesit, i just dont see any issues after configure it in my emacs. for example, when i first open golang code after re-configure, the messages shows:
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.
CodeCompost · 2026-08-25 05:30:20 UTC
The section under "User Lisp Directory" seems incomplete. I was expecting a second paragraph.
brabel · 2026-08-25 06:47:14 UTC
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.
bpye · 2026-08-25 06:56:43 UTC
Is there a better way to get started with Emacs than the built in tutorial? I've tried a couple times (due to increasing annoyance with VS Code), but have struggled to get to a point where I feel productive enough.
mickeyp · 2026-08-25 07:01:44 UTC
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.
My book is of course an option also, but it costs money.
alfiedotwtf · 2026-08-25 12:52:07 UTC
Your book should be mandatory. It’s a gem and I think I’d still be on Vim or VSCode without it!
mickeyp · 2026-08-25 13:48:07 UTC
Thank you so much for the kind words :) I'm glad I could help you switch!
kstrauser · 2026-08-25 14:21:03 UTC
So, uh, v31 update coming soon? crossing-fingers.gif
mickeyp · 2026-08-25 15:00:32 UTC
Yeah I'll be working on it. Been busy on another product (see bio) which has taken up a year-plus of my time. Hence the lack of regular postings!
kstrauser · 2026-08-25 15:50:49 UTC
Lovely! I’ll check it out.
mickeyp · 2026-08-25 17:57:12 UTC
Happy to supply you with a beta key; give me a ping via email.
code-blooded · 2026-08-25 16:47:17 UTC
Wonderful. I'll be among buyers the day it releases
mickeyp · 2026-08-25 17:56:55 UTC
I'll happily hook you up with a key for you to play around with - feel free to drop me an e-mail.
roundcan7998 · 2026-08-25 08:52:15 UTC
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
throwa356262 · 2026-08-25 11:29:01 UTC
Can you expand this a little bit? What makes this book different?
roundcan7998 · 2026-08-25 13:30:09 UTC
It speaks to people like you and me.
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)
jmmv · 2026-08-25 10:11:27 UTC
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...
sinker · 2026-08-25 17:00:32 UTC
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.
stackghost · 2026-08-25 17:05:18 UTC
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.
everybodyknows · 2026-08-26 00:23:44 UTC
An LLM is great at writing a first shot at key bindings to suit your taste, and recipes for Emacs' four syntactically different yet functionally overlapping configuration schemes.
The maybe complementary, or at least deterministic source of advice is old school 'M-x info'.
yewenjie · 2026-08-25 12:04:16 UTC
Now would be the time for someone to use AI to rewrite the Emacs core to make it faster.
cod3ninja · 2026-08-25 12:05:18 UTC
Nice, Emacs is so old school!
qazxcvbnm · 2026-08-25 12:09:47 UTC
I’ve heard that the graphical browser is back on emacs! Xwidgetwebkit was dead since emacs 29, and for a while I was left pining for a good graphical browser in emacs.
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!
kkylin · 2026-08-25 16:51:47 UTC
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.
> 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.
pvaldes · 2026-08-25 15:26:45 UTC
what?, goldenrod face vanished?
akoster · 2026-08-25 15:46:56 UTC
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!
prometheus76 · 2026-08-25 12:29:06 UTC
The part the author shared about the huge overhead cost of firing up emacs, especially in a multi-user environment (I learned about emacs vs vi holy war back on a multi-user Solaris environment), our Unix professor strongly encouraged us to learn vi. He said "vi is part of every standard Unix install, so when you ssh into a box, you'll always have your editor and it won't steal all the CPU from the other users when you fire it up."
Feels monumental to see that come to an end decades later.
jasperry · 2026-08-25 13:01:26 UTC
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.
jibal · 2026-08-26 06:35:33 UTC
I think you're quite confused. Emacs always avoided a huge startup hit by loading elisp code into temacs (bare bones emacs that only exists when building it) and then dumping it with unexec to produce the emacs that is distributed. A decade ago, glibc stopped supporting unexec and emacs had to switch to a different method of incorporating the elisp code and avoiding the startup time, but the unexec code was still there. Now, a decade later, that code--which was not being used--has finally been removed.
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).
prometheus76 · 2026-08-26 18:18:18 UTC
Well, this was over 30 years ago that I was sitting in that class, and the resources the emacs required vs vi was definitely part of the discussion. We were working in a shared environment on a solaris system, and if the whole class fired up emacs for a class session, the effects were definitely experienced by all the users on the system at the time.
prometheus76 · 2026-08-26 18:22:09 UTC
I'll add a little context. I mentioned that it was 30 years ago. My personal computer at the time was a 486DX-50 with 16 MB of RAM, and the mainframe we were tied to had maybe 2 GB of Ram? For 200+ users to share. It's easy to forget how far hardware has developed since then.
jibal · 2026-08-26 22:58:32 UTC
Just say "oh, I see".
TacticalCoder · 2026-08-26 09:53:08 UTC
> The part the author shared about the huge overhead cost of firing up emacs
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.).
Comments
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.
https://protesilaos.com/
Also available in video form on YouTube.
I think he's a great resource for coming to modern emacs.
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.
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.
[1]: https://protesilaos.com/emacs/
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.
[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.
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.
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'.
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!
> 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!
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.