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!
> 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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
How unfortunate that glibc has removed support for unexec. Although it wasn't a very widely used feature, it seems like the kind of orthogonal powerful feature that distinguishes one platform from another, like Unix's fork(), or I/O redirection, or strace, or not needing different system calls to write text and binary files. In an alternate universe, you could imagine unexec support being generalized to support broader classes of applications for purposes such as process migration, high-availability failover, and bug reproduction (as with rr), instead of being removed.
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.
Yeah, me too. I hear Ada has something really weird, but I don't know anything about it. Smalltalk and especially Gemstone also have some really different approaches, and OS/400 also does some pretty strange stuff.
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.
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.
I've just started getting into emacs and am almost done with what I think is my final config (just adding vertico, consult and marginalia, haven't added them all, but got vertico and consult working in a mostly default state, still need to tweak a bit).
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).
I can't say it has any particular bearing on the usage of emacs, but within the last year or so I started using a "ortholinear" keyboard (an ergodox-ez) and found that qwerty was uncomfortable on that with how lousy my typing form is. I tried a couple different layouts and landed on something called "middlemak"[1]. Of all the ones I tried, it really felt like the one with the least overall finger travel and awkward things to type in my day to day software development work (though there are still some odd letter combinations courtesy of english borrowing from everyone), and it's not a massive change from qwerty so a lot of muscle memory actually could carry over. Workman and Colemak both had some awkward motions or finger strains that just didn't work for me.
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].
I went from `vi` to `vim` to `neovim` to a spiritual successor `helix`, and here's Emacs at release 31 still the dominant fork of the emacs family of editors. Impressive.
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.
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.
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.
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.
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'.
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.
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!
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.
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.
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).
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.
my .emacs and associated configs have accumulated decades of pretty poorly organized customizations, a lot of it related to things I used with ancient projects that I haven't touched since. Probably time to do a reset back to current defaults and reapply the stuff I actually use.
I love emacs. I used emacs for 20 years. But I haven't used it as much since moving to codex/claude. Even with vterm, can't really use TUIs that well inside IMO. Or at least, had way too many issues where emacs/vterm was the culprit
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.
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.
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.
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.
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.
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.
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.
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.
I do not know what temacs is, but on Slackware 15 w/emacs-30.2, temacs does not exist. I wonder if temacs is something used in other operating systems ?
I hope to upgrade to 31.1 on Slackware either today or tomorrow. I will grab the source from Slackware current and compile/install :)
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.
I used the "regular" slackbuild. native-compilation slackbuild fails with a missing library.
But Emacs 31.1 is in Slackware Current, so when Slackware is released I will be on it :)
you should report that bug to ccrypt, emacs is getting a lot more strict about lexical binding support (for good reason). it just needs ;; -- lexical-binding: t/nil -- at the top of the file.
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.
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
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
(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.)
Honesty, not such a wild proposition in 2026 with new hardware generations offering the same or less RAM and storage!
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
[1]: https://protesilaos.com/emacs/
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.
[0] https://lwn.net/Articles/673724/
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/...
Eventually, Mastering Emacs will be free!
See also my reading guide: https://www.masteringemacs.org/reading-guide
My book is of course an option also, but it costs money.
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...
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)
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!
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).
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.
I hope to upgrade to 31.1 on Slackware either today or tomorrow. I will grab the source from Slackware current and compile/install :)
But Emacs 31.1 is in Slackware Current, so when Slackware is released I will be on it :)
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.
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.)