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!
WalterGR
There’s some great stuff in there.
> As part of our continuous struggle to make Emacs simpler, we’ve removed the `margin` face, so text shown in display margins will now use the same `default` face as the rest of buffer text. Our long-term goal is to remove faces completely, thus leaving the Emacs with just two colors, so we gradually remove more and more faces as we go.
pvaldes
what?, goldenrod face vanished?
kstrauser
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.
mickeyp
AI is very good at Emacs Lisp - esp GPT. So you'll have an easier time around today!
kstrauser
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
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
Same. lsp-mode's quite nice, to be sure, but eglot's also excellent and it's been completely sufficient for my needs.
thom
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.
tom_alexander
> 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
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.
wmedrano
Are there any Zed features you're going to miss? Is the AI notable?
iLemming
> 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.
kstrauser
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.
Not being built-in into the core, means nothing. Emacs just doesn't operate that way.
peri-cl
> "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.
kstrauser
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.
tapete1
> “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.
ubercore
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
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
And if the correct keystrokes are burned into your muscle memory, you can opt for Evil mode.
froh
I infer you don't use magic?
kstrauser
Why would you infer that? Magit’s great!
froh
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
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.
imglorp
You mean magit?
alfiedotwtf
After realising you can modify the transient menus pretty easily, magit has been even more wonderful now
aquariusDue
Wait, what? Do tell more, please!
alfiedotwtf
When viewing a transient menu, C-x l
froh
yes. autocorrect and the wrong glasses turn magit into magic
fittingly so but still annoying. srry
rtpg
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.
rwl
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.
rootnod3
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
And coachings!
iLemming
> 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.
MarsIronPI
Have you read through the Emacs Lisp Intro and Elisp manuals in Info? The latter is especially helpful as a reference.
Protesilaos has a book on this topic. Might be what you are looking for.
wmedrano
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.
kragen
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.
Asooka
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 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.
kragen
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.
jibal
That was 10 years ago.
kragen
I thought the same thing 10 years ago.
bpye
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
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
Your book should be mandatory. It’s a gem and I think I’d still be on Vim or VSCode without it!
mickeyp
Thank you so much for the kind words :) I'm glad I could help you switch!
kstrauser
So, uh, v31 update coming soon? crossing-fingers.gif
mickeyp
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!
code-blooded
Wonderful. I'll be among buyers the day it releases
mickeyp
I'll happily hook you up with a key for you to play around with - feel free to drop me an e-mail.
kstrauser
Lovely! I’ll check it out.
mickeyp
Happy to supply you with a beta key; give me a ping via email.
roundcan7998
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
Can you expand this a little bit? What makes this book different?
roundcan7998
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
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
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
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
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'.
wmedrano
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.
wormius
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).
tpmoney
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].
> As always, my book, Mastering Emacs is 31% off for the next week to celebrate the release also.
Eventually, Mastering Emacs will be free!
jake_and_fatman
As the Techlead says, only if you're time is worthless.
markstos
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.
whimblepop
GNU Emacs isn't the first Emacs, although it's still an impressively long-lived and vivacious one.
qazxcvbnm
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
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.
prometheus76
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.
jibal
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
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
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
Just say "oh, I see".
TacticalCoder
> 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.).
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.
CodeCompost
The section under "User Lisp Directory" seems incomplete. I was expecting a second paragraph.
brabel
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.
hirvi74
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
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
Have also struggled with this- would be great to see a fix
yanhangyhy
i just gived it a try. works like a charm, treesitter + lsp. i asked cursor to help me with the config.
hirvi74
Omg, I can finally return to my beloved for all the languages I use. Thank you for the update.
yanhangyhy
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.
SoftTalker
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.
flowerlad
I wish they would make Arm64 Windows binaries a standard part of the release. Intel is on its way out.
jmclnx
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 :)
jmclnx
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 :)
bygosh
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.
bos
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.
mickeyp
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.
diegoeche
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
awesome, I was looking for a libghostty emacs terminal about a month ago. vterm just does not cut it for me.
sinker
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.
systems
for me the highlight of this release is the docked speedbar, it took them too long, but its finally here
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
shevy-java
This operating system just got better!
pkal
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.
brabel
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
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.
mickeyp
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
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.
Quitschquat
Anyone know if Zaretskii resigned over the portable dumper?
vocx2tx
He's in the MAINTAINERS file[0], and the person with the most commits in 2016-2026 period, so no.
The pdumper has been around for yonks, and afaik Zaretskii is still maintaining.
jake_and_fatman
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
Why would he resign over that? He's threatened to resign over removing DOS support, but has no problem with pdumper.
jake_and_fatman
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
Oh. Correction noted. That's all water under the bridge now though. You can't hold grudges forever.
yewenjie
Now would be the time for someone to use AI to rewrite the Emacs core to make it faster.
cod3ninja
Nice, Emacs is so old school!
thataccount
It is clear that this article simply does not know the power of Vi/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.)
thataccount
I always liked the command structure of Vim better.
iLemming
Well, Vim is not some concrete implementation, it's not like "Photoshop", where it means a specific product line, it's an idea. "The power of Vim" is its grammar, the grammar is design, and designs port - that's why Helix, Kakoune, Evil-mode, Meow, etc. exist. I agree that the "command structure" you're referring to may feel better than modifier-chord scheme of vanilla Emacs, where commands are a flat namespace - a mixed bag of bindings with no algebra connecting them.
However, the years of muscle-memory might be deceiving. Vim's objects are text-shaped - the design has no idea of what a function or an expression is. Vim's grammar is excellent but its nouns are approximations. The modern answer perhaps to keep the grammar and upgrade the nouns, which is what tree-sitter text objects attempt of doing.
Anyway, my main point is not about the grammar, but about the grand idea. The idea of Vim is a beautiful, pragmatic model and it can be perfectly used outside of Neovim. If you truly want to take it to another level, maybe consider combining it with the power of Emacs.
Innovation and insight rarely happen within a single substrate - you typically need to explore intersections of divergent disciplines. Emacs itself is rooted in another grand idea, arguably one of the most important ideas in all the history of computer science - a practical notation for lambda calculus widely known as "Lisp". Once you understand the immense, pragmatic value of that idea, it eliminates any skepticism you might have held against it.
If you think Emacsians don't get vim, well, you're misinformed. There are thousands of vimmers who choose to be viming in Emacs. Because Emacs vims better. As a die-hard vimmer I can attest.
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.
https://protesilaos.com/
Also available in video form on YouTube.
I think he's a great resource for coming to modern emacs.
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.
Obviously, only a Mac user would need to do that. Every other person will just do this customization the normal way.
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.
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.
fittingly so but still annoying. srry
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.
[0] https://lwn.net/Articles/673724/
I'd love to read a good history of the different development styles. I know we often have a good exploration of the parts of an executable file. I don't recall seeing a good exploration of different compilation/build styles through the years.
Mostly I've noticed unusual compilation/build styles when they come into conflict with version control systems. One weird one was when I was contracting 01996 to 01997 at TCSI, Teknekron Communication Systems, Incorporated, which I guess was a spinoff of Teknekron dedicated to building telco software. I was working on a project called STNMS, the SONET Tunnel Network Management System. There were some pretty funny things about the project, including some amazing recursive acronym soup. One of the major components of STNMS was the NGEMS TOM, which stood or NGDLC Element Management System TCSI Object Manager, or, fully expanded, New Generation Digital Loop Carrier Element Management System Teknekron Communication Systems, Incorporated, Object Manager.
Anyway, one of the interesting things about the system was that it was built on a distributed object system like CORBA or PARC's ILU or DCOM or eventually Java RMI, where you would invoke methods on objects, and the methods could execute in another process or even on another machine. So the NGEMS GUI would invoke methods on NGEMS-related objects which were actually implemented by code running in the NGEMS TOM, which might be on another machine, so that you could be running the NGEMS GUI on lots of machines, all calling methods on the same NGEMS-related objects, which could therefore avoid any concurrency-related bugs, I guess.
I'm not totally sold on this actually being a good idea, among other things, because the various TOMs stored their data in an INFORMIX-ONLINE SQL database server, which had pretty decent concurrency control already, and was pretty fast.
I was responsible for maintaining the bug-tracking system, the INFORMIX servers in the test environment, the build system, and the software version-tracking system, which was a pile of csh scripts built on top of RCS, running on NFS. And I was also responsible for doing a full system build, I think about once a month, which usually took me about a week of tweaking things. I was 19, and it was 01996, so I didn't know any better. I'd learned SQL and RCS by reading the O'Reilly books on the plane out to California.
Anyway, TCSI wasn't using a CORBA ORB or an ILU ORB or a DCOM ORB for their RPC layer. They'd written their own ORB, whose name I forget, but its IDL was generally called "MOSU", and lived in files with the .mosu extension. This stood for Methods, Objects, and something or other I can't remember; just as with any ORB IDL, you needed to define the class interfaces and methods and parameters that you could invoke through the ORB, so that the clients and servers would agree on what they were. You'll have to forgive me for the vagueness — it's been almost 30 years, and even at the time I wasn't writing code that went into the system, just tweaking it until it compiled so the 30 or so programmers and testers on the project could get on with their work.
The thing that caused trouble with version control was the .moslog file that accompanied the .mosu file, assigning numbers to methods and objects.
For efficiency, there was a small positive integer assigned to each of the methods, objects, etc., that the ORB's protocol could refer to. The client and server also had to agree on these numbers, just as in Protocol Buffers you need a unique tag number for each field that all users of the .proto agree on. You could solve this by burdening programmers with the need to declare these numbers in their IDL (the .mosu), as protobuf does; or you could solve it by reaching agreement on them when the connection was opened and then doing the mapping dynamically during the session, as X-Windows's XInternAtoms() does; but the MOSU IDL compiler solved it by assigning these MOS numbers automatically, starting with the smallest natural numbers.
But, to ensure that it assigned them consistently, it would log the assignments to the .moslog file.
Therefore, the .moslog file had to be checked in to source control, but the build process might modify it. And, if different programmers added things to the same .mosu, their .moslog changes were almost certain to conflict, because the compiler would assign the same next number to both things — conflicts I seem to recall I sometimes had to clean up by hand. Of course this required sneaking around behind the back of the version-tracking system, since RCS requires exclusive locks to modify a file, but often the programmers did have to sneak around thus in order to get their work done, for example because someone else had the .mosu and the .moslog locked that day.
TCSI is now dead and gone; https://en.wikipedia.org/wiki/Teknekron_Corporation tells me that it was bought by Rocket Software in 02003. I think the STNMS project failed, and BellSouth, the company that was paying TCSI to build it, also no longer exists. So, I doubt anybody has used these primitive tools in 20+ years, and I haven't seen them described anywhere publicly before, perhaps because TCSI foolishly thought they were a competitive advantage at the time. (I hope I haven't made too many errors in my recollections.) But it's interesting what we can learn from them for the future.
Today, there's a somewhat similar thing that happens with generative testing systems like Hypothesis: when they find a failing "instance" of a property-based test, they record it in a database of failing tests, so that you can always use it in the future. So the "build process", or rather the test process, sometimes produces data that must be checked in to the version tracking system. This doesn't mesh well with conventional version-control workflows, and especially established continuous-integration systems which blow away the universe when the test suite finishes running.
Of course, training AI neural networks doesn't fit cleanly into the conventional version-control model either.
See also my reading guide: https://www.masteringemacs.org/reading-guide
My book is of course an option also, but it costs money.
Just get it already
Folks in the modern age, who want to get up to speed with an old trusty tool, without the biases of other folk getting in the way.
You get up to speed enough, that you can then go find your own way.
Mickey’s writing is conversational yet pithy and laconic. (in a very good way)
TBH, I had used Emacs before VSCode and had accumulated a bunch of cruft in my .emacs configuration, and I never felt it was "mine" anyway...
It also helps to learn upfront the idiosyncratic terms and concepts like buffers, windows, frames, yanking, killing, etc.
Most of these terms map one-to-one to more familiar nomenclature like copy, paste, etc.
Buffers is a concept a bit more unique and integral to emacs. It's easier to understand in practice than in reading.
Most importantly though, emacs is a lisp machine, and exposes the highest level of granularity, and enables the finest level of customization for the user.
No thanks.
Instead, literally just start using it and ask an LLM for help as you go.
The maybe complementary, or at least deterministic source of advice is old school 'M-x info'.
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!
Since then, friendly AI emacsers stuffed usable versions of graphical browsers into emacs, but those never felt truly emacs-native and did leave quite a bit to be desired (embr, the least unusable of the pack, being referred to here; among its warts - unreliable link detection; forcing “tabs” within a buffer; non deterministic unresponsiveness; causing C-g to lag).
Finally I can rid myself of such impurities from core emacs!
Feels monumental to see that come to an end decades later.
None of that has anything to with emacs vs vi -- the point that your professor was making was that vi was distributed by default with UNIX so it was always there, whereas emacs needed to be installed (which wasn't even an option on servers).
TFA's wording on that is a bit misleading.
My Emacs with no config starts in 0.1s (110 ms). My Emacs with my huge config (between 3 000 to 4 000 lines of custom Elisp code) starts in 1.2s or so.
And then of course modern day Emacs is so stable that the thing can stay up for weeks without needing a restart.
It's been a very long time that the "cost of firing up Emacs" is smaller than the cost of firing up 99% of all the software out there (looking at you AppImage , flatpaks, browsers, any desktop app really, etc.).
Stock Emacs: 110ms (Debian Trixie / AMD 7700X / WD-SN850X SSD).
Boom.
By installing the grammars on the user's behalf, I think I might be in luck!
I don't remember the exact issue, but I remember having to dig through the release histories of each of the poorly documented ABI version for each language to find whichever versions was compatible.
I've got my fingers crossed.
github.com/mickeynp/combobulate
Tree-sitter grammar for `go' is missing; install it? y
Cloning repository
Compiling library
Library installed to /Users/xxx/.emacs.d/tree-sitter/libtree-sitter-go.dylib
looks pretty good.
I hope to upgrade to 31.1 on Slackware either today or tomorrow. I will grab the source from Slackware current and compile/install :)
But Emacs 31.1 is in Slackware Current, so when Slackware is released I will be on it :)
In emacs, everything is available, everything is a primitive function, everything can be inspected, the documentation (ie, contextual food for agents) is built-in, and emacs itself can be piloted entirely through function calls. This means that agents can fully control an emacs instance and run that closed loop (write, test, evaluate, repeat) with almost complete information - which makes the [given prompt] : [results conforming to spec] relationship much tighter than in most environments.
dired mode is fine, and i appreciate it, but having the folder view docked on the left, was something i missed in emacs, happy its finally here
Regarding :vc and :load-path, this was obsoleted transitively due to the obsoleting of package-vc-install-from-checkout, which has portability issues. Bug#80604 goes into the background for this. This is NOT an obsoletion of the :vc keyword for use-package.
Regarding package-autosuggest, this is disabled because it doesn't interest most users. It is targeted at new users who aren't familiar with the packages, and might be interested in new major modes. Experienced users are generally either familiar with the packages and use them or prefer to stay in fundamental mode. The minor mode is enabled as part of the newcomers theme!
No mention of package-review-policy, which especially in the "age of AI" is an important feature is you want to be careful about external code you are using on your system.
Oh and on the topic of the newercomers theme, the reason it is not mentioned "higher up" in the NEWS file, besides it being the wrong section, is that it is highlighted on the splash screen, where new users are going to find it, instead of a NEWS file.
Deprecating :vc + :load-path without expressing why is a curious oversight. And "portability issues" is all fine and good, but why embed custom git clone + build grammar code in the treesit.el file if VC checkout portability is a concern? Surely VC is better at it than a bunch of brittle string concat code in treesit.el I do not understand why one part works and another supposedly does not.
The change is especially infuriating as for most of us it actually worked fine, and user-lisp directory does not solve the retrieval and setup problem, which `use-package` for all its flaws at least standardises.
Most users probably do care about discoverability of related packages, existing user or not. But that's in the eye of the beholder.
`package-review-policy` is security kabuki theatre. Someone who wants to harm an Emacs user can find many other ways of doing so with or without this flag.
This is the kind of research that I would expect an article like yours to make. It is totally fair to contact the people who worked on this, instead of being smug about it and caricaturing the Emacs maintainers as conservative.
[0] https://github.com/emacs-mirror/emacs/blob/master/admin/MAIN...
Bruv would run the same guilt trip maybe once every couple years, the last time being the c-ts-mode snafu of his own creation. That time, someone snarkily replied, "Please do [resign]!" Bruv hasn't done it again since. This emacs thing is all he has.
And Emacs is strictly more powerful than Vim. :)
(I mean that seriously, actually— I don't think people who have used both but prefer Vim would generally list "more powerful" among their reasons for preferring Vim. It's usually more about not liking Lisp, some kind of "minimalism", or a different sensibility about composability.)
However, the years of muscle-memory might be deceiving. Vim's objects are text-shaped - the design has no idea of what a function or an expression is. Vim's grammar is excellent but its nouns are approximations. The modern answer perhaps to keep the grammar and upgrade the nouns, which is what tree-sitter text objects attempt of doing.
Anyway, my main point is not about the grammar, but about the grand idea. The idea of Vim is a beautiful, pragmatic model and it can be perfectly used outside of Neovim. If you truly want to take it to another level, maybe consider combining it with the power of Emacs.
Innovation and insight rarely happen within a single substrate - you typically need to explore intersections of divergent disciplines. Emacs itself is rooted in another grand idea, arguably one of the most important ideas in all the history of computer science - a practical notation for lambda calculus widely known as "Lisp". Once you understand the immense, pragmatic value of that idea, it eliminates any skepticism you might have held against it.
If you think Emacsians don't get vim, well, you're misinformed. There are thousands of vimmers who choose to be viming in Emacs. Because Emacs vims better. As a die-hard vimmer I can attest.