This stuff all looks great, I can't wait to upgrade to 31 and then forget about all of it and just keep using Emacs the same way I have been for the past 20 years, /again/
Yes. I had to briefly visit the world of VSCode during a period of time when it had better AI integration than emacs did, but since I got Claude working well inside of emacs I've returned to 100% emacs. There just isn't anything like the old editors, built in the 80x24 terminal era, for getting huge swathes of code on your screen at once. I run a standard widescreen monitor with three vertical windows for emacs, each of which I often will break into two frames, so I can have up to six contexts active at once. I rarely do, but I frequently have 2 and 3. That's my entire 4K screen, full of code, usefully full of code. I'm not an IDE hater but they do put an awful lot of stuff on the screen that on a proportional basis I'm just not using as much as I use the code editor.
I had been getting somewhat nervous about emacs' long term prospects about 10 years ago. I would read the release notes for major versions and generally not be particularly excited about anything. Somewhere around treesitter something seems to have revitalized the project. It may well have been treesitter that revitalized it overall. You end up with a lot more wood behind fewer arrows when the project is able to put more work into generally-useful tools rather than every single language community maintaining their own separate mode for each language.
Now I am more excited about the major releases; for instance term issues are an issue for me with the aforementioned Claude integration. Not enough to stop me, but annoying. At the risk of saying something inflammatory to emacs fans, I feel like emacs is catching up to everything else better now... but it is catching up. It's getting easier to recommend it again as something you may want to seriously consider as a power-tool editor and not just something I used because I had 15 years of finger-experience with it and no significant reason to change. AI has eaten a lot of the IDE tools for me and you can type into a text box in emacs as well as you can anything else.
I still occasionally bring up VSCode now to use the debugger, I still don't feel like I have as nice an experience with that as I do with emacs, but my debugging habits have always been able to deal with doing something a little extra to do a debugging session. By its very nature, you're committing some time to the process just to do the debugging itself, no matter how slick the UI for it may be, so a bit of overhead isn't so bad.
> Now I am more excited about the major releases; for instance term issues are an issue for me with the aforementioned Claude integration. Not enough to stop me, but annoying.
Being a co-maintainer, I'm a bit biased, but I think you should try Ghostel (https://github.com/dakra/ghostel) if you aren't already. And if you are, you should report bugs so we can fix them :)
I quickly skimmed and did not really see any compelling reason why I should switch from vterm. Then I went into the docs and found compelling performance numbers (10MB cat test: 220ms vs 550ms; throughput: 75MB/s vs 18 MB/s). You could market your project better by showing these numbers :)
Hehe, the feature that enables that (feeding reading the PTY and feeding the VT parser off the main Emacs thread) only got merged today. But the rendering even before this was a lot faster than Vterm.
Otherwise, I think the main advantage over Vterm and other Emacs terminal emulators is that it handles modern fancy TUIs a lot better than Vterm. It's backed by libghostty-vt so supports all the new fangled escape codes. It has a bunch of tricks to force fallback glyphs to the terminal monospace grid to remove the flickering effect when the glyph cells change size during TUI animations, most notably in Claude Code. Btop and Yazi runs great too, if you're into that sort of thing.
>In computing, the robustness principle is a design guideline for software that states: "be conservative in what you do, be liberal in what you accept from others". It is often reworded as: "be conservative in what you send, be liberal in what you accept". The principle is also known as Postel's law, after Jon Postel, who used the wording in an early specification of TCP.[1]
>In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.
It's terribly inefficient for emacs vi emulation mode to actually quit emacs when you type ":q", because it takes much longer for emacs to start up than vi, and people use a long-running emacs a lot differently than they use disposable vi's.
UniPress[1] Emacs's vi emulation mode would actually flip you over to an emacs shell buffer when you typed :q, and the shell would recognize when you typed "vi foo.c" and flip back over to a vi emulator buffer instead of actually running vi, but INSTANTLY, since changing buffers in a running emacs was much faster than actually starting up a new vi process.
So die-hard vi users didn't have to re-learn their muscle memory, and could just stay in the same emacs all the time, while the same old emacs alternately flipped between pretending to be a shell, and pretending to be vi.
I use emacs --daemon with emacsclient for this. I always have a running emacs instance, and connect with the client. Opening and quitting a client is near instant.
being scared of emacs pinkie was a major contributor for me back as a student to learning vim. I remap ctrl to CAPS LOCK on all my computers as one of the first things but I still end up using my pinkie. I've been playing with the idea of switching ctrl to the spacebar at least in non insert mode though because I still end up using my pinkie a lot when scrolling with Ctrl+E for example
Systems like Emacs that are hyper-configurable via a text file seem tailor made for modern LLM's. If you've got a little bit of Emacs experience but bounced off of it because the learning curve was too steep I highly recommend diving back in with your agent. Agents are really good at setting up and maintaining your .emacs/init.el.
Doing this for Neovim at work and it’s so much fun. I justify the slopped config to myself because I want to get work done rather than learn the config of some random Neovim package and how it interacts with the rest of the system.
I can just ask Claude, “make leader / toggle a terminal at the bottom of the screen , and leader t swaps it to the right side” and it’ll just do that. I liked a theme but I wanted it to also change the status line of the focused window, and it just did that for me. I had an issue where the file explorer would freeze for a few seconds, and Claude figured out it was a bad interaction with the git in our toolchain, etc etc.
I have my very own text editor that I customized in plain English! I could’ve learnt spent hours learning Neovim’s style of Lua, researching packages, debugging, etc, but this gets the same stuff done way faster and lets me get to work. This was the biggest thing that kept me going back to either a preconfigured Vim serup like LazyVim or vscode. Definitely recommend.
A programmable editor really is so amazing now. You can have a LLMs whip up anything you can think of in minutes. Ive used neovim for a long time but never really customized it much. Now I’ve got tons of plugins and can add new features on a whim.
I’ve been thinking of trying out emacs because I think the native gui can probably be even more powerful
I know a bunch of people (including me) who decades ago wished they had a private sendmail.cf expert at their elbow, and even a few sendmail.cf experts who were sick and tired of always being asked to help random people with their sendmail.cf file for free.
Maybe there will be a resurgance of terribly obscure totally unique quirky configuration files for all these vibe coded apps, unique enough that they don't appear in the training data, so you have to hire real humans to sit at your elbow and help you!
I'm happy to see these improvements. One thing that has always been annoying with Emacs is how much configuration is required to get a modern editor going. Things like Doom Emacs, and Spacemacs try to solve that problem, but both feel far removed from vanilla emacs. I wish Emacs came with several presets so with a single line, you could transform the editor to different base points. For example, most devs want treesitter highlighting and LSP enabled by default. Why not have a preset like (preset-base-ide-1), so we don't need 200 lines of configuration before we can function? Instead we could build off of a much closer starting point.
This comment shows up on every single emacs thread and for the life of me I can't understand why. It takes one line in a shell to pull down a premade config and if that were to be built on, who would decide what gets put in? I don't think it's worth anyone's time to decide what everyone needs in a premade config.
You are just worrying for no good reason. Doom Emacs and Spacemacs are both very good; being far removed from vanilla emacs is not a problem to be worried about.
Indeed. I myself am on Doom Emacs but I've increasingly been thinking of moving over to vanilla Emacs. I'm a bit worried about the transition period due to all the keybind differences but I'm sure it's not too bad.
Tell your agent what parts of Doom Emacs you actually use, and ask it to build a minimal init.el containing only those parts. You're probably only using ~2% of Doom, so the resulting init.el will likely only be a few hundred lines, and most of those lines will be comments and key bindings.
It won't be a perfect transition, but it will make it a lot smoother.
Don't get me wrong, I'm loving Doom and have used it full time for a few years now. But over time I've started being uncomfortable with the fact that I don't fully understand the editor, don't fully appreciate the difference between what comes in as part of vanilla Emacs and as a Doom feature, and I feel like I am depending on a huge bunch of code and configuration I might not really even need.
Selfishly I wasn't willing to spend the time to master Emacs proper back then, but with the LLM craze now I find it much easier to hack on my configs.
I think it is cultural. It's kinda like building your own lightsaber as a Jedi. The part of Emacs/Vim initiation is building your own configuration that works for you. Setting up plugins, keybindings, colorschemes etc. It's part of the fun of it (at least for me).
As a Vim user (just admitting to my ignorance here), is it not feasible to make something like this yourself? Emacs is said to be flexible and extensible enough, or at least I’m under the impression that it has that reputation.
I imagine it would take a lot of time, maybe. Any greybeards that do this?
It is fairly trivial to make something 'like it', but what people advocating for this stuff want is for it to be shipped with regular plain old normal GNU Emacs so they can set it up quickly and easily in an Emacs installation on a work laptop (and it may make it easier to convert people to Emacs for those who care about that).
I spent a lot of time making my own elisp config for a custom emacs experience and ended up getting something similar to Doom Emacs. So, I just switched to use Doom :)
Yeah, it'd be easy, but the hard part is getting people to agree what the standard will be.
Plus, frankly, a lot of people (myself included) who want a richer experience are pretty much just happy turning on emacs keybindings in VSCode or IntelliJ or whatever.
> Why not have a preset like (preset-base-ide-1), so we don't need 200 lines of configuration before we can function? Instead we could build off of a much closer starting point
First you need to define what is that much better starting point? Something VSCode like? I find VS Code a bad example of software development tooling (anemic file management, integration with external tooling is cunbersome, VCS integration is flimsy, Code viewing is poor,…).
VSCode is a swiss knife. It has a few tools that are handy for occasional needs. But Vim and Emacs provide a complete toolbox. Learn it once and be set for life.
The only reason we still have IDE is kafkaesque ecosystems that requires expansive and custom tooling just to make sense of it. People can use vim to write code for the Linux kernel but needs XCode for a 5 screens app.
Bedrock Emacs is pretty much this, its what I finally used after I declared config-bankruptcy with Doom, and it gave me the room I needed to get my own setup together
Reading Rahul's post I got excited to build Emacs 31 from source, but reality occurred and I decided to wait for the release. I also like his articles on setting up Emacs.
I don't care what tools other developers use but in January I made my two dev Macs 'VSCode free' and use Emacs for everything. Feels better!
For decades I would spend tons of time experimenting with my Emacs setups but in the last few years I have been shifting to more out of the box experiences. I did write my own agentic coding platform in Emacs Lisp but I keep that separate from .emacs and .emacs.d
The bulk of the Mastering Emacs blog is a decade old at this point, but its philosophy and the information it provides is still very relevant for any graybeard wanting to get up to date.
Wow, auto install treesitter grammars, editable xref, transposing window layouts, speed bar as a side window in frame, I had no idea any of these things were coming and were all some passing thoughts I’ve had in the last few weeks “it would be cool if this was supported OOTB”. Some dreams do come true!
I have been using Emacs for more than a decade, and I was always excited about the features. But with AI, something has changed. I no longer type/edit that much. Recently, LSP stopped working, and I was completely oblivious to it for about a week. Earlier, something like this would have been a major annoyance.
Emacs is more than a dev environment for coders. Some of us here use it for everything that can possibly be represented in text form: our TODO lists, our calendar, our RSS reader, our mail reader, etc. Me, I even maintain billing spreadsheets for a side business as Org-Mode tables. New features in the latest Emacs releases, and in successive releases of individual packages, have brought some nice improvements in those areas.
Very cool! Looking forward to try out the xref and markdown features. The latter becomes increasingly important since the developer community at large seems to disagree with org-mode being the superior syntax...
back in 2nd year of university I remember thinking that vim is complicated so i went with Emacs. Now after using vim for couple years , I can't imagine going to Emacs and learning it. The availability of vim emulation in majority of text editors and IDEs has been a lifesaver
although the brief time I used Magit I was enamored I gotta say. I tried lazygit recently and it evoked the same feeling I had when trying Magit for the first time
I recently sifted through a bunch of tagged entries in a text file, where each entry had a json array of image names, but the images resided on a remote server. I basically wanted a program that could detect if the cursor was on an image name, and display it on the right.
There's a bajillion ways to do this, some might even involve writing an html file and launching a remote server and tunneling and using a browser and what not. But no! ChatGPT wrote 20 lines of elisp code. I add a tramp basepath, open the text file, and got exactly what I needed. Need any behavior changes, callbacks, transformations? Modify, eval expression, new behavior!
I asked ChatGPT what other system I can use to achieve the same effect. The best answer it gave was neovim. No, neovim can't do that with the same degree of ease.
Disappointing and amazing at the same time.
The drawback of the emacs approach in my case is the tramp latency. To speed things up we'd want to add prefetch and that's gonna be much more than 20 lines and C-x e
I use emacs --daemon instead of tmux inside my agent sandbox for session permanence and portability. A full editor rather than a layer between me and my editor. I can even waypipe the client windows if I want mouse support.
I do the dinosaur version of this, with screen and xpra. Works great. CC and codex being terminal-native may make terminal-based (or at least terminal-comfortable) editors seem more natural to a broader set of people.
Why use screen? Just leave your emacs --daemon running, and when you reconnect, run emacsclient and all your buffers are back. And you only have to learn one method for arranging frames rather than both emacs' and screen's.
The issue was traced to library xinput2, when compiled with '--without-xinput2' the issue does not occur. But I do not know if that is something that Emacs can address.
It's nice to hear the emacs terminal emulator has gotten some love, after all the controversy about the nasty language that used to be in its source code, which rms moved out to a separate file after somebody complained.
Open source with profanity in comments is statistically better than code without it:
DonHopkins on July 6, 2023 | parent | context | favorite | on: Open source code with profanity in comments is sta...
The original terminal emulator terminal.el in gnu emacs, written by mly (Richard Mlynarik), was particularly salty. I finally tracked down a copy, but it looks like somebody complained and in 1990 it was begrudgingly cleaned up a bit, so some of the worst stuff was moved out into a separate file called term-nasty.el for posterity (you, here, now), so as not to give "in to the pressure to censor obscenity that currently threatens freedom of speech and of the press in the US" (oh, Richard <3 ):
;; disgusting unix-required shit
;; Are we living twenty years in the past yet?
(defun te-losing-unix ()
nil)
[...]
;; (A version of the following comment which might be distractingly offensive
;; to some readers has been moved to term-nasty.el.)
;; unix lacks ITS-style tty control...
(defun te-process-output (preemptable)
;;>> There seems no good reason to ever disallow preemption
(setq preemptable t)
[...]
;; I suppose if I split the guts of this out into a separate
;; function we could trivially emulate different terminals
;; Who cares in any case? (Apart from stupid losers using rlogin)
[...]
(?\C-b . te-backward-char)
;; should be C-d, but un*x
;; pty's won't send \004 through!
;; Can you believe this?
[...]
;; Did I ask to be sent these characters?
;; I don't remember doing so, either.
;; (Perhaps some operating system or
;; other is completely incompetent...)
[...]
;;-- Not-widely-known (ie nonstandard) flags, which mean
;; o writing in the last column of the last line
;; doesn't cause idiotic scrolling, and
;; o don't use idiotische c-s/c-q sogenannte
;; ``flow control'' auf keinen Fall.
"LP:NF:"
;;-- For stupid or obsolete programs
"ic=^p_!:dc=^pd!:al=^p^o!:dl=^p^k!:ho=^p= :"
;;-- For disgusting programs.
;; (VI? What losers need these, I wonder?)
"im=:ei=:dm=:ed=:mi:do=^p^j:nl=^p^j:bs:")))
[...]
(setq te-process
(start-process "terminal-emulator" (current-buffer)
"/bin/sh" "-c"
;; Yuck!!! Start a shell to set some terminal
;; control characteristics. Then start the
;; "env" program to setup the terminal type
;; Then finally start the program we wanted.
(format "%s; exec %s"
te-stty-string
(mapconcat 'te-quote-arg-for-sh
(cons program args) " ")))))
;;; term-nasty.el --- Damned Things from terminfo.el
;;; This file is in the public domain, and was written by Stallman and Mlynarik
;;; Commentary:
;; Some people used to be bothered by the following comments that were
;; found in terminal.el. We decided they were distracting, and that it
;; was better not to have them there. On the other hand, we didn't want
;; to appear to be giving in to the pressure to censor obscenity that
;; currently threatens freedom of speech and of the press in the US.
;; So we decided to put the comments here.
;;; Code:
These comments were removed from te-losing-unix.
;(what lossage)
;(message "fucking-unix: %d" char)
This was before te-process-output.
;; fucking unix has -such- braindamaged lack of tty control...
And about the need to handle output characters such as C-m, C-g, C-h
and C-i even though the termcap doesn't say they may be used:
;fuck me harder
;again and again!
;wa12id!!
;(spiked)
;;; term-nasty.el ends here
Note to the gentle readers: "wa12id" stands for "with a 12 inch dildo".
Of course, terminal.el is actually useful, albeit not terribly powerful.
(and terminal.el is pretty mild compared to some of the other things I've seen written by mly. :-))
Incidentally, a lot of terminal.el has been rewritten in version 19.
Too bad... I liked all the variable names and comments in the original.
Jamie Zawinski, Aug 5, 1992, 12:40:38 AM
In the FSF-distributed Emacs 19, the obscenities (will) have been stripped from terminal.el, though they are preserved in a file called term-nasty.el, to avoid appearing to bow to the censors.
In Lucid GNU Emacs, terminal.el will remain as nasty as it ever was.
-- Jamie "Truth, Justice, and the Fucking First Amendment" Zawinski
This stuff all looks great, I can't wait to upgrade to 31 and then forget about all of it and just keep using Emacs the same way I have been for the past 20 years, /again/
1. Upgrade to Emacs version +1
2. Remove MELPA packages that are now part of Emacs
3. Go to step 1 when new version comes out
LOL. So true!
Except for tree-sitter. That's something I'll be investing time in.
"Is anyone still using emacs?"
Yes. I had to briefly visit the world of VSCode during a period of time when it had better AI integration than emacs did, but since I got Claude working well inside of emacs I've returned to 100% emacs. There just isn't anything like the old editors, built in the 80x24 terminal era, for getting huge swathes of code on your screen at once. I run a standard widescreen monitor with three vertical windows for emacs, each of which I often will break into two frames, so I can have up to six contexts active at once. I rarely do, but I frequently have 2 and 3. That's my entire 4K screen, full of code, usefully full of code. I'm not an IDE hater but they do put an awful lot of stuff on the screen that on a proportional basis I'm just not using as much as I use the code editor.
I had been getting somewhat nervous about emacs' long term prospects about 10 years ago. I would read the release notes for major versions and generally not be particularly excited about anything. Somewhere around treesitter something seems to have revitalized the project. It may well have been treesitter that revitalized it overall. You end up with a lot more wood behind fewer arrows when the project is able to put more work into generally-useful tools rather than every single language community maintaining their own separate mode for each language.
Now I am more excited about the major releases; for instance term issues are an issue for me with the aforementioned Claude integration. Not enough to stop me, but annoying. At the risk of saying something inflammatory to emacs fans, I feel like emacs is catching up to everything else better now... but it is catching up. It's getting easier to recommend it again as something you may want to seriously consider as a power-tool editor and not just something I used because I had 15 years of finger-experience with it and no significant reason to change. AI has eaten a lot of the IDE tools for me and you can type into a text box in emacs as well as you can anything else.
I still occasionally bring up VSCode now to use the debugger, I still don't feel like I have as nice an experience with that as I do with emacs, but my debugging habits have always been able to deal with doing something a little extra to do a debugging session. By its very nature, you're committing some time to the process just to do the debugging itself, no matter how slick the UI for it may be, so a bit of overhead isn't so bad.
> Now I am more excited about the major releases; for instance term issues are an issue for me with the aforementioned Claude integration. Not enough to stop me, but annoying.
Being a co-maintainer, I'm a bit biased, but I think you should try Ghostel (https://github.com/dakra/ghostel) if you aren't already. And if you are, you should report bugs so we can fix them :)
I quickly skimmed and did not really see any compelling reason why I should switch from vterm. Then I went into the docs and found compelling performance numbers (10MB cat test: 220ms vs 550ms; throughput: 75MB/s vs 18 MB/s). You could market your project better by showing these numbers :)
Hehe, the feature that enables that (feeding reading the PTY and feeding the VT parser off the main Emacs thread) only got merged today. But the rendering even before this was a lot faster than Vterm.
Otherwise, I think the main advantage over Vterm and other Emacs terminal emulators is that it handles modern fancy TUIs a lot better than Vterm. It's backed by libghostty-vt so supports all the new fangled escape codes. It has a bunch of tricks to force fallback glyphs to the terminal monospace grid to remove the flickering effect when the glyph cells change size during TUI animations, most notably in Claude Code. Btop and Yazi runs great too, if you're into that sort of thing.
Plus a bunch of other things!
Is it conservative in what it sends, and liberal in what it accepts?
Can you elaborate a bit on what you are asking about?
The name Ghostel sounds like a tribute to the Ghost of John Postel, whose law is a good thing for a terminal emulator to respect:
https://lawsofux.com/postels-law/
https://en.wikipedia.org/wiki/Robustness_principle
>In computing, the robustness principle is a design guideline for software that states: "be conservative in what you do, be liberal in what you accept from others". It is often reworded as: "be conservative in what you send, be liberal in what you accept". The principle is also known as Postel's law, after Jon Postel, who used the wording in an early specification of TCP.[1]
>In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.
And Ghostel support recently landed in claude-code-ide.el!
Why not use agent-shell? It makes the whole experience great.
Also claude-code-ide.el. try these
The two complaints I hear is:
1.Memorizing how to use it has a big learning curve.
2.Wrist pain from pressing button combinations all the time.
Otherwise plenty of people still use it and it's great. Just hard to pick up for new users.
I've only ever used emacs in vim mode (evil-mode). Its vim emulation is the best I've seen anywhere.
It's terribly inefficient for emacs vi emulation mode to actually quit emacs when you type ":q", because it takes much longer for emacs to start up than vi, and people use a long-running emacs a lot differently than they use disposable vi's.
UniPress[1] Emacs's vi emulation mode would actually flip you over to an emacs shell buffer when you typed :q, and the shell would recognize when you typed "vi foo.c" and flip back over to a vi emulator buffer instead of actually running vi, but INSTANTLY, since changing buffers in a running emacs was much faster than actually starting up a new vi process.
So die-hard vi users didn't have to re-learn their muscle memory, and could just stay in the same emacs all the time, while the same old emacs alternately flipped between pretending to be a shell, and pretending to be vi.
[1] "Evil Software Hoarder Emacs": https://news.ycombinator.com/item?id=26113192
I use emacs --daemon with emacsclient for this. I always have a running emacs instance, and connect with the client. Opening and quitting a client is near instant.
being scared of emacs pinkie was a major contributor for me back as a student to learning vim. I remap ctrl to CAPS LOCK on all my computers as one of the first things but I still end up using my pinkie. I've been playing with the idea of switching ctrl to the spacebar at least in non insert mode though because I still end up using my pinkie a lot when scrolling with Ctrl+E for example
Don't use your pinkie or any finger. Use the meat of your hand to hit the control key.
Systems like Emacs that are hyper-configurable via a text file seem tailor made for modern LLM's. If you've got a little bit of Emacs experience but bounced off of it because the learning curve was too steep I highly recommend diving back in with your agent. Agents are really good at setting up and maintaining your .emacs/init.el.
Doing this for Neovim at work and it’s so much fun. I justify the slopped config to myself because I want to get work done rather than learn the config of some random Neovim package and how it interacts with the rest of the system.
I can just ask Claude, “make leader / toggle a terminal at the bottom of the screen , and leader t swaps it to the right side” and it’ll just do that. I liked a theme but I wanted it to also change the status line of the focused window, and it just did that for me. I had an issue where the file explorer would freeze for a few seconds, and Claude figured out it was a bad interaction with the git in our toolchain, etc etc.
I have my very own text editor that I customized in plain English! I could’ve learnt spent hours learning Neovim’s style of Lua, researching packages, debugging, etc, but this gets the same stuff done way faster and lets me get to work. This was the biggest thing that kept me going back to either a preconfigured Vim serup like LazyVim or vscode. Definitely recommend.
A programmable editor really is so amazing now. You can have a LLMs whip up anything you can think of in minutes. Ive used neovim for a long time but never really customized it much. Now I’ve got tons of plugins and can add new features on a whim.
I’ve been thinking of trying out emacs because I think the native gui can probably be even more powerful
I agree. It's amazing. I feel like I've got a private Emacs consultant at my elbow.
I know a bunch of people (including me) who decades ago wished they had a private sendmail.cf expert at their elbow, and even a few sendmail.cf experts who were sick and tired of always being asked to help random people with their sendmail.cf file for free.
Maybe there will be a resurgance of terribly obscure totally unique quirky configuration files for all these vibe coded apps, unique enough that they don't appear in the training data, so you have to hire real humans to sit at your elbow and help you!
I'm happy to see these improvements. One thing that has always been annoying with Emacs is how much configuration is required to get a modern editor going. Things like Doom Emacs, and Spacemacs try to solve that problem, but both feel far removed from vanilla emacs. I wish Emacs came with several presets so with a single line, you could transform the editor to different base points. For example, most devs want treesitter highlighting and LSP enabled by default. Why not have a preset like (preset-base-ide-1), so we don't need 200 lines of configuration before we can function? Instead we could build off of a much closer starting point.
This comment shows up on every single emacs thread and for the life of me I can't understand why. It takes one line in a shell to pull down a premade config and if that were to be built on, who would decide what gets put in? I don't think it's worth anyone's time to decide what everyone needs in a premade config.
>if that were to be built on, who would decide what gets put in?
A small number of people with taste and experience.
Like one hopes to be the case for every opinionated preset profile set.
You are just worrying for no good reason. Doom Emacs and Spacemacs are both very good; being far removed from vanilla emacs is not a problem to be worried about.
Indeed. I myself am on Doom Emacs but I've increasingly been thinking of moving over to vanilla Emacs. I'm a bit worried about the transition period due to all the keybind differences but I'm sure it's not too bad.
Tell your agent what parts of Doom Emacs you actually use, and ask it to build a minimal init.el containing only those parts. You're probably only using ~2% of Doom, so the resulting init.el will likely only be a few hundred lines, and most of those lines will be comments and key bindings.
It won't be a perfect transition, but it will make it a lot smoother.
I'm also a Doom user, albeit a new one. What is making you consider the switch?
Don't get me wrong, I'm loving Doom and have used it full time for a few years now. But over time I've started being uncomfortable with the fact that I don't fully understand the editor, don't fully appreciate the difference between what comes in as part of vanilla Emacs and as a Doom feature, and I feel like I am depending on a huge bunch of code and configuration I might not really even need.
Selfishly I wasn't willing to spend the time to master Emacs proper back then, but with the LLM craze now I find it much easier to hack on my configs.
I think it is cultural. It's kinda like building your own lightsaber as a Jedi. The part of Emacs/Vim initiation is building your own configuration that works for you. Setting up plugins, keybindings, colorschemes etc. It's part of the fun of it (at least for me).
And then slowly over 20 or so years deleting all of it.
I think I'm down to about 110 lines of ~/.vimrc now :}
As a Vim user (just admitting to my ignorance here), is it not feasible to make something like this yourself? Emacs is said to be flexible and extensible enough, or at least I’m under the impression that it has that reputation.
I imagine it would take a lot of time, maybe. Any greybeards that do this?
It is fairly trivial to make something 'like it', but what people advocating for this stuff want is for it to be shipped with regular plain old normal GNU Emacs so they can set it up quickly and easily in an Emacs installation on a work laptop (and it may make it easier to convert people to Emacs for those who care about that).
I spent a lot of time making my own elisp config for a custom emacs experience and ended up getting something similar to Doom Emacs. So, I just switched to use Doom :)
Yeah, it'd be easy, but the hard part is getting people to agree what the standard will be.
Plus, frankly, a lot of people (myself included) who want a richer experience are pretty much just happy turning on emacs keybindings in VSCode or IntelliJ or whatever.
Claude: configure my Emacs such that … has worked pretty well for me lately.
What are these things you have that makes Emacs a modern editor?
I have cua-mode and don't show startup message. What else do I need to modernize Emacs?
treesitter (with easily installable grammars - a big pain point) / LSP integration OOTB / themability
Plus now agent integration (aka GPTEL)
These are all trivial to implement?
`treesitter` grammars _are_ easy to install.
`eglot` is available OOTB, `lsp-mode` is easy to install and configure if you prefer.
`gptel` is easy to install and configure.
Being many things, even if "easy to install" individually, can add up to a hassle to pick, research, install, and configure them.
Why even use `emacs` if you're not willing to learn the basics? There are plenty of alternatives that cater to that preference.
> Why not have a preset like (preset-base-ide-1), so we don't need 200 lines of configuration before we can function? Instead we could build off of a much closer starting point
First you need to define what is that much better starting point? Something VSCode like? I find VS Code a bad example of software development tooling (anemic file management, integration with external tooling is cunbersome, VCS integration is flimsy, Code viewing is poor,…).
VSCode is a swiss knife. It has a few tools that are handy for occasional needs. But Vim and Emacs provide a complete toolbox. Learn it once and be set for life.
The only reason we still have IDE is kafkaesque ecosystems that requires expansive and custom tooling just to make sense of it. People can use vim to write code for the Linux kernel but needs XCode for a 5 screens app.
Bedrock Emacs is pretty much this, its what I finally used after I declared config-bankruptcy with Doom, and it gave me the room I needed to get my own setup together
https://codeberg.org/ashton314/emacs-bedrock
Reading Rahul's post I got excited to build Emacs 31 from source, but reality occurred and I decided to wait for the release. I also like his articles on setting up Emacs.
I don't care what tools other developers use but in January I made my two dev Macs 'VSCode free' and use Emacs for everything. Feels better!
For decades I would spend tons of time experimenting with my Emacs setups but in the last few years I have been shifting to more out of the box experiences. I did write my own agentic coding platform in Emacs Lisp but I keep that separate from .emacs and .emacs.d
I realize I've missed a lot.
Someone should write an Emacs guide for people who haven't meaningfully touched their .emacs since the early 2000s
The bulk of the Mastering Emacs blog is a decade old at this point, but its philosophy and the information it provides is still very relevant for any graybeard wanting to get up to date.
There's a lot of Emacs information on the internet, and your agent has been trained on it.
For real, ask your agent to do anything in Emacs and it simply knows how to do it.
Wow, auto install treesitter grammars, editable xref, transposing window layouts, speed bar as a side window in frame, I had no idea any of these things were coming and were all some passing thoughts I’ve had in the last few weeks “it would be cool if this was supported OOTB”. Some dreams do come true!
I have been using Emacs for more than a decade, and I was always excited about the features. But with AI, something has changed. I no longer type/edit that much. Recently, LSP stopped working, and I was completely oblivious to it for about a week. Earlier, something like this would have been a major annoyance.
Emacs is more than a dev environment for coders. Some of us here use it for everything that can possibly be represented in text form: our TODO lists, our calendar, our RSS reader, our mail reader, etc. Me, I even maintain billing spreadsheets for a side business as Org-Mode tables. New features in the latest Emacs releases, and in successive releases of individual packages, have brought some nice improvements in those areas.
In 2026 I'm using the editor less and using magit a lot more. IOW, emacs has become more indispensable, not less.
Very cool! Looking forward to try out the xref and markdown features. The latter becomes increasingly important since the developer community at large seems to disagree with org-mode being the superior syntax...
back in 2nd year of university I remember thinking that vim is complicated so i went with Emacs. Now after using vim for couple years , I can't imagine going to Emacs and learning it. The availability of vim emulation in majority of text editors and IDEs has been a lifesaver
although the brief time I used Magit I was enamored I gotta say. I tried lazygit recently and it evoked the same feeling I had when trying Magit for the first time
Excited to try out the native frame transposition this update and how it plays with pgtk
Nice to know sr-speedbar can finally be retired. It works fine, but fewer external packages means simpler config.
I recently sifted through a bunch of tagged entries in a text file, where each entry had a json array of image names, but the images resided on a remote server. I basically wanted a program that could detect if the cursor was on an image name, and display it on the right.
There's a bajillion ways to do this, some might even involve writing an html file and launching a remote server and tunneling and using a browser and what not. But no! ChatGPT wrote 20 lines of elisp code. I add a tramp basepath, open the text file, and got exactly what I needed. Need any behavior changes, callbacks, transformations? Modify, eval expression, new behavior!
I asked ChatGPT what other system I can use to achieve the same effect. The best answer it gave was neovim. No, neovim can't do that with the same degree of ease.
Disappointing and amazing at the same time.
The drawback of the emacs approach in my case is the tramp latency. To speed things up we'd want to add prefetch and that's gonna be much more than 20 lines and C-x e
"Is anyone still using emacs?"
I use emacs --daemon instead of tmux inside my agent sandbox for session permanence and portability. A full editor rather than a layer between me and my editor. I can even waypipe the client windows if I want mouse support.
I do the dinosaur version of this, with screen and xpra. Works great. CC and codex being terminal-native may make terminal-based (or at least terminal-comfortable) editors seem more natural to a broader set of people.
Why use screen? Just leave your emacs --daemon running, and when you reconnect, run emacsclient and all your buffers are back. And you only have to learn one method for arranging frames rather than both emacs' and screen's.
Thanks for sharing, frou_dh! Author here btw :)
>treesit-auto-install-grammar
Sweet. GLP1 for my .emacs!
Thanks for your work.
Please, if you have something to do with Emacs, can you review this for NetBSD and OpenBSD when using gtk3:
https://www.unitedbsd.com/d/1621-emacs-30-wxaw
The issue was traced to library xinput2, when compiled with '--without-xinput2' the issue does not occur. But I do not know if that is something that Emacs can address.
It's nice to hear the emacs terminal emulator has gotten some love, after all the controversy about the nasty language that used to be in its source code, which rms moved out to a separate file after somebody complained.
Open source with profanity in comments is statistically better than code without it:
https://blog.desdelinux.net/en/open-source-with-profanity-in...
https://news.ycombinator.com/item?id=36621699
DonHopkins on July 6, 2023 | parent | context | favorite | on: Open source code with profanity in comments is sta...
The original terminal emulator terminal.el in gnu emacs, written by mly (Richard Mlynarik), was particularly salty. I finally tracked down a copy, but it looks like somebody complained and in 1990 it was begrudgingly cleaned up a bit, so some of the worst stuff was moved out into a separate file called term-nasty.el for posterity (you, here, now), so as not to give "in to the pressure to censor obscenity that currently threatens freedom of speech and of the press in the US" (oh, Richard <3 ):
https://opensource.apple.com/source/emacs/emacs-59.0.80/emac...
1990-08-26 Richard Stallman (rms@mole.ai.mit.edu)
* terminal.el: Move possibly offensive comments to term-nasty.el.
https://www.digiater.nl/openvms/freeware/v10/emacs/common/li...
[...]
[...] [...] [...] [...] [...] [...] [...] [...]https://www.digiater.nl/openvms/freeware/v10/emacs/common/li...
Note to the gentle readers: "wa12id" stands for "with a 12 inch dildo".Jamie Zawinski kept Lucid Emacs nasty:
https://groups.google.com/g/gnu.misc.discuss/c/U5oXKOfWinQ/m...
Noah Friedman, Aug 3, 1992, 4:54:20 AM
In article <15i2n9...@hal.com> wood...@hal.com (Nathan Hess) writes:
>In article <FRIEDMAN.9...@nutrimat.gnu.ai.mit.edu>, friedman@gnu (Noah Friedman) writes:
>>It's by no means necessary, but it's funny.
>Along the same lines, look at lisp/terminal.el
Of course, terminal.el is actually useful, albeit not terribly powerful.
(and terminal.el is pretty mild compared to some of the other things I've seen written by mly. :-))
Incidentally, a lot of terminal.el has been rewritten in version 19.
Too bad... I liked all the variable names and comments in the original.
Jamie Zawinski, Aug 5, 1992, 12:40:38 AM
In the FSF-distributed Emacs 19, the obscenities (will) have been stripped from terminal.el, though they are preserved in a file called term-nasty.el, to avoid appearing to bow to the censors.
In Lucid GNU Emacs, terminal.el will remain as nasty as it ever was.
-- Jamie "Truth, Justice, and the Fucking First Amendment" Zawinski