Rendered at 00:48:20 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
k_bx 5 days ago [-]
> — Sensible file handling: backups and auto-saves in a cache/ directory, recentf for recent files, clean buffer naming with uniquify
It's crazy to me how out of the box when you edit nginx file at /etc/nginx/sites-enabled/foo it creates another file foo~ there and nginx tries to load that too
When I tried to ask emacs reddit community they started attacking me for changing the default that only I need and fits everyone perfectly.
Still can't believe I'm the only one finding that default amazingly bad.
parasti 5 days ago [-]
I would fault nginx here instead. Tilde-suffixed backups is an old convention used by vim and emacs among others. Definitely older than nginx.
sshine 5 days ago [-]
The ~foo as backup convention is not part of any standard.
Using hidden files is a stronger convention, e.g. .foo.swp or .foo~.
But nginx's sites-enabled also doesn't filter those.
It's a very simple mechanism that assumes what you put in that directory is a website configuration.
Adding backup files here and there is considered spam, no matter how old it is.
It's the second thing I fix in either Vim or Emacs: Put backup files in a central location. (The first is proper indentation/spacing rules.)
scbrg 5 days ago [-]
> The ~foo as backup convention is not part of any standard.
Emacs does foo~ by default, not ~foo.
In either case, you're not really supposed to edit files in sites-enabled. That directory is expected to contain symlinks to files in sites-available. I'm not going to say with any certainty that one of the reasons for this indeed is that the pattern (which was used by apache as well - and perhaps other things before it) protects against accidentally reading backup files, but it's not impossible.
So there's definitely a case of holding it wrong if you end up with backup files in that directory.
dec0dedab0de 4 days ago [-]
I liked doing symlinks so the site configuration is with the rest of the site, but that was before containers when it was common to host a bunch of sites on one instance apache or nginx.
rolandog 5 days ago [-]
> The ~foo as backup convention is not part of any standard.
> [...]
> It's the second thing I fix in either Vim or Emacs: Put backup files in a central location. (The first is proper indentation/spacing rules.)
Perhaps not a standard, but you yourself admit it's the default behavior.
Though I agree that the simple mechanism acts ... er,... simply, shouldn't it be at the very least aware of the default behavior of common editors?
NetMageSCW 4 days ago [-]
What standard would that be?
jibal 5 days ago [-]
There was no mention of ~foo
jibal 4 days ago [-]
P.S. I'm not wrong. Perhaps someone got confused about what "suffix" means.
sshine 2 days ago [-]
It’s not that you are wrong.
Just that the message does not contribute to the conversation.
Neither does this one.
jibal 2 days ago [-]
But it DID contribute to the conversation ... it corrected an error/misunderstanding. If I didn't think I was contributing, I wouldn't have commented. You seem to have a different ethic.
I won't comment further, as we are now off topic (thanks to you).
AJRF 5 days ago [-]
Surprised to hear people told you not to change that - one of the earliest bits of advice I got on using emacs is to set the location of those files to a hidden directory in your home folder.
antonyh 4 days ago [-]
Changing this to save elsewhere is the #1 improvement to Emacs. It bugs me whenever any software creates backups in the same location as the original.
That said, Nginx is also wrong and shouldn't do that.
k_bx 5 days ago [-]
I was proposing to make default where those files are not created, since Emacs is actually surprisingly great out of the box with no configuration, except for this "little" thing. Apparrently, some people believe it's perfect as it is
mksybr 5 days ago [-]
It should default to a single location maybe a XDG directory instead of polluting every directory
NetMageSCW 4 days ago [-]
What happens when you edit multiple files from different folders with the same name?
jlarocco 4 days ago [-]
I tell emacs to create all of the files in "~/.backups", and it names them using the full pathname with "/" replaced with "!". So "~/foo/bar.txt" -> "!home!username!foo!bar.txt~"
baby 5 days ago [-]
I raise you my .DS_store
alwillis 4 days ago [-]
In a terminal on macOS, to disable writing .DS_Store files to network file shares:
I also set create-lockfiles to nil. I think you can theoretically keep the lockfiles and the clean directory by using lock-file-name-transforms to place the lockfiles somewhere sensible but I didn't bother.
Without this I had to be careful not to acciddentally commit stuff like ".#filename.txt".
Note that tramp will kvetch if you do this, but it still works fine.
globular-toast 5 days ago [-]
This was one of the very first things I added to my config over a decade ago:
(setq backup-directory-alist '(("." . ".~")))
e40 5 days ago [-]
Been using gnu emacs since the 80s and it’s one of the first things I changed. Did you figure it out? If not I can dig up the answer tomorrow.
k_bx 5 days ago [-]
Yes I’ve added this to hundreds of containers and vms at this point
(setq make-backup-files nil)
noosphr 5 days ago [-]
Just use tramp mode instead.
The fact it can do multi-hop edits is far too much power for us mere mortals.
opan 4 days ago [-]
(n)vim can also do this, if you've set up an ssh alias in your ssh config for your multi-hop destination you just list it where the hostname would go. e.g.
nvim scp://remotemachine/.config/emacs/init.el
For the same reason you can use sshfs, sftp, and rsync with multi-hop. Gotta love openssh!
k_bx 5 days ago [-]
It's a very different experience:
- I already have tmux launched, if ssh drops – I can continue
- I don't have to match windows to ssh sessions -- just have them in my tmux
noosphr 5 days ago [-]
Yes, tmux vastly inferior to tramp.
Tramp runs in your local Emacs and edits files remotely. It can also launch processes remotely and keep track of them.
maleldil 5 days ago [-]
How does it handle things like LSPs?
draxil 5 days ago [-]
emacs users who are hostile to you configuring things, aren't really getting the point IMO :)
raverbashing 5 days ago [-]
The list of things emacs users don't get seems to get longer per day so I'm not surprised at the reaction OP got, just disappointed
(but I still think this is on nginx more than emacs - unless they really mean foo~ and not .foo~ )
jlarocco 4 days ago [-]
> The list of things emacs users don't get seems to get...
There are a ton of Emacs users, and it's doesn't make much sense to talk about them as a group like that, no more than if I were to say, "The list of things Windows users don't get..."
k_bx 4 days ago [-]
They are hostile to me proposing a better (IMO) default
eej71 4 days ago [-]
It depends on what you mean by default and whose default.
You can change your own defaults quite easily!
Changing the default setup with emacs that has been shipping for > 30 years is tough.
Getting nginx to ignore a well established pattern by a well established editor seems equally sensible and perhaps more doable. Yes?
k_bx 4 days ago [-]
By default I mean whatever you get by doing `sudo apt-get install emacs-nox`
I disagree about "tough". Emacs has changed for the better in new releases quite drastically in the last years in my experience.
5 days ago [-]
jlarocco 4 days ago [-]
I won't defend the automatic backup file, because it annoyed me, too.
But it's easy to disable or have them created somewhere else, which is more than you can say for most software lately.
k_bx 4 days ago [-]
I just realized that `apt install emacs-nox` is a great editor in containers and VMs. I just have to disable it every damn time (for regular and root user). Defaults would be better.
jlarocco 3 days ago [-]
I don't mean to be condescending, but since you just learned about emacs-nox... If you haven't already, try tramp mode to edit files in containers and VMs. It also lets you edit local files using sudo.
There's also a docker package for managing containers - similar concept and UI to magit, but for managing Docker. Not as life changing as magit, but convenient.
Anyway, the problem with changing the default after all this time is that everybody would want the new default to be different, and changing it now would meaning breaking things for long time users who depend on the current default. And TBH if you're setting up a container and installing Emacs, it's very little extra work to copy over a .emacs file that fixes everything the way you like.
muyuu 5 days ago [-]
there's pros and cons
using the same directory drastically reduces the amount of assumptions about your system's permissions and your own installation (or lack thereof)
old school *nix editors typically do something like emacs and vi typically do, whereas old WinDOS/Mac single-user systems would have an installation file and a cache system-wide, and post NT and OS-X they have roughly the same but in a centralised user directory that is not system-wide, but is located as if it were (different evolution path)
shevy-java 5 days ago [-]
I always disable those auto-backup-files features in any editor I use. Never understood why that was the default-on for so many editors.
imiric 5 days ago [-]
It can be handy. It gives you an additional safety net on top of the VCS that runs automatically in the background. It doesn't take much to configure it to your liking, e.g. [1].
It made more sense when running editors over tenuous telnet connections was more common
dhosek 5 days ago [-]
The kids really have no idea how tenuous computing in general was back in the olden days. Some of the stability issues in the 20th century translated to modern systems would be akin to black smoke coming out of your computer if you happened to have the wrong two programs running at the same time.
anthk 4 days ago [-]
I am no kid but screen(1) dates back to 1987 and any wise sysadmin would put that advice on every ~/.login or /etc/motd so the user could run 'screen' at login, some keybinding to detach screen(1) and 'screen -r' on coming back by telnet.
dhosek 4 days ago [-]
I never used screen back in the day (I was primarily a VMS guy then), but that man page is one of the best-written man pages I’ve come across: informative, friendly and just the right level of detail.
k_bx 5 days ago [-]
I do too, it’s just that I’ve realised that emacs-nox is awesome container / vm editor out of the box, this backup thing is the only most annoying part (and Ubuntu 22.04 emacs packages expired cert)
obezyian 4 days ago [-]
> Disabling C-z (suspend) because accidentally suspending Emacs in a terminal is never fun
This reminds me of a story from a past job. I have to get it out of my system.
There was this bearded sysadmin guy who was very proud of his "15 years of experience", and was quick to scold us new employees for every little thing he could.
He used vim, and every now and then would say that it's a good editor, but kinda "unstable". Crashed a lot, he said.
You probably know where this is going.
One day, one of us sat next to him and discovered many suspended vim jobs in his shell (this was the kind of guy that doesn't power off his computer).
He was fat-fingering C-z all the time, and has never heard of job control - bg, fg, etc.
15 years of experience.
dsr_ 4 days ago [-]
Sometimes it's 15 repetitions of one year.
raverbashing 4 days ago [-]
Interesting story, but I'm surprised the OP would disable Cmd-z because that is used all the time with vim
I know you might prefer to run a shell on emacs (or vim) but something only the full terminal can do what you need it to do
MonkeyClub 3 days ago [-]
> but something only the full terminal can do what you need it to do
There's always `M-x term` for a full terminal.
jimbokun 5 days ago [-]
This article shows how Emacs remains a beautiful, relevant project several decades after it was first created. The core design and implementation’s ability to evolve into something still useful today and competitive with modern tools is an amazing achievement.
Also, with LLMs driving so much of current development it potentially makes Emacs even more competitive relative to modern IDEs. Development can be driven primarily by an agent like Claude Code from the command line, then navigating and tweaking the code, handling Git commits, etc with Emacs.
I imagine an LLM would be very good at writing Elisp to leverage EMacs’ strong core functionality to make Emacs work exactly how you want. This author managed to do it by hand, but I imagine someone starting now with an LLM could get there much faster.
widdershins 5 days ago [-]
> I imagine an LLM would be very good at writing Elisp to leverage EMacs’ strong core functionality
Yes, they are pretty good. I have set up GPTel (an excellent Emacs package for interacting with LLMs) with some tools allowing it to run Elisp, inspect files (Elisp functions know what file they were defined in, so it's easy to find stuff) and read Emacs documentation. LLMs use this to good effect, and iterate on my config very nicely.
pqs 5 days ago [-]
Indeed. I always used Emacs, but not, thanks to AI agents, Emacs is better than ever, as it can write the lisp I can't write, and it can read the docs I don't have the time to read.
pwillia7 4 days ago [-]
Emacs would be a pretty badass "OS" for LLM agents to use... has anyone explored and written something up on that yet? Perhaps emacs commands would give agents even more power than just shell commands ?
calgoo 4 days ago [-]
Yea i have been vibe-coding a claw agent in emacs lisp to see how it works.... It.... kind of works.
Claude has been really good at writing and debugging the code for me.
tsm 4 days ago [-]
I'm far from an LLM power user, but I've found ChatGPT to be quite good at debugging my init.el and also writing little extensions I wish I had.
uncletaco 5 days ago [-]
It’s interesting how your comment did not talk about anything that’s unique to emacs.
rgoulter 4 days ago [-]
The core of it is described by the post you're replying to as "I imagine an LLM would be very good at writing Elisp to leverage EMacs’ strong core functionality to make Emacs work exactly how you want."
Emacs is highly customisable. There's not really a hard difference between "configuration" and "extension". Whereas with e.g. VSCode, very few people would write their own extensions. -- So it's a good point that with LLMs, the barrier to customise Emacs to exactly how you want it is even lower.
I'd also argue that since practically everything in Emacs is text (as opposed to a rich GUI interface), Emacs itself ought to make for a nice interface to LLM functionality.
wilkystyle 5 days ago [-]
> That means the code is sketchy sometimes, sure, but it's in my control. I wrote it, I understand it, and when it breaks, I know exactly where to look.
This resonates with me so hard. I'm not a "no external packages" purist, but there are a number of pieces of functionality that I wrote for myself because there wasn't anything quite like what I wanted.
One example is a function to expand the region (selection) to any arbitrary set of pairing delimiters that I define in a defvar (parens, quotes, brackets, or I can can supply a custom left/right regex for matching). Then, when I execute the function, it waits for a second keypress, which is the trigger key I've defined for that matching pair, and it will expand the region to the left and the right until it meets the applicable delimiter.
Repeating the same key presses results in selecting the left and right delimiters themselves, and another repeat will extend to the next set of matching delimiters, and so on.
Even though I use a treesitter-based expand-region plug-in, my custom function is still invaluable for when I want to jump past a series of valid treesitter object expansions, or when certain text objects are just not defined in treesitter.
Some of the helpful custom expansions I have defined are:
"w" to select what Vim considers a lowercase-w word
Space to select what Vim considers an uppercase-W word
"$" to select ${...}-style expressions
"/" to select everything between forward slashes
"*" to select between asterisks (useful when editing markdown)
It's really an invaluable function for me, personally, but I always talk myself out of trying to open-source it because it has some gotchas and limitations, and I just don't want to be on the hook for trying to make everyone who uses it happy.
throwaway27448 5 days ago [-]
> "w" to select what Vim considers a lowercase-w word
?!? Wtf does this mean and how did vi come up
keithnz 5 days ago [-]
vim has two "word" motions, w and W, the lowercase w motion will see punctuation as a word boundary (as well as whitespace ) W only considers whitespace
bluebarbet 5 days ago [-]
Mind blown. Now I'm wondering if swapping `w` and `W` in the config is worth the penalty of diverging from the defaults. Decisions decisions.
throwaway27448 5 days ago [-]
Sure. how was that relevant to explaining their keymapping? Why would you not simply directly describe the behavior as you did rather than sending the same amount of energy to route people through an entirely unrelated editing paradigm?
dhosek 5 days ago [-]
Because any mention of Emacs must bring out the vi people, just as any mention of vi must bring out the Emacs people.
Because you people are cracking your eggs from the wrong end!
rkomorn 5 days ago [-]
> Because you people are cracking your eggs from the wrong end!
That's because both ends are wrong. Eggs should be cracked from the side.
Can't believe this still needs to be said on this forum in 2026.
throwaway27448 4 days ago [-]
> Can't believe this still needs to be said on this forum in 2026.
And we still don't have a usable editor outside of emacs
drob518 5 days ago [-]
Cue RMS giving the Church of Emacs skit…
Ferret7446 5 days ago [-]
The "why" is kinda sketchy. The difference between what is shipped in Emacs and in ELPA is somewhat arbitrary. In fact, there are many built in packages that have their updates shipped in ELPA, meaning if you aren't using ELPA then your builtin packages might have unpatched bugs.
There's also no reason why you have to literally write everything yourself either. You can find open source licensed packages, read them to understand them, and then copy them into your config. Doing everything from scratch is a waste of time unless you enjoy the process (in which case go nuts).
It's roughly equivalent to trying to discover all of our scientific knowledge yourself from scratch vs taking "for granted" the knowledge discovered by your forebears. There is no shame or disadvantage in doing so.
Also, a critical objection:
> Writing your own packages is the best way to learn Elisp
Absolutely not. Reading a language is crucial. If all you do is write, you will pigeonhole into weird practices and generally fail to improve. Only by reading stuff written by others can you learn, as you're exposed to what other people do right and wrong, both of which will be different from you.
Of course, writing your own packages is also necessary, but not sufficient alone.
porcoda 5 days ago [-]
> Absolutely not. Reading a language is crucial.
I don't think the post implied that this package writing activity was a write-only activity where reading and learning is strictly forbidden.
> You can find open source licensed packages, read them to understand them, and then copy them into your config. Doing everything from scratch is a waste of time unless you enjoy the process (in which case go nuts).
The post clearly indicates the relatively large set of open source packages they looked at and understood before doing their own packages. The author graciously acknowledges them and their influence on the work:
"Emacs Solo doesn't install external packages, it is deeply influenced by them. diff-hl, ace-window, olivetti, doom-modeline, exec-path-from-shell, eldoc-box, rainbow-delimiters, sudo-edit, and many others showed me what was possible and set the bar for what a good Emacs experience looks like. Where specific credit is due, it's noted in the source code itself."
tom_ 5 days ago [-]
It's nothing like rediscovering everything. Not only is it only Emacs, but it's also been designed by people with a goal of being straightforward to use by people. And whatever you create just needs to be useful to you personally anyway.
I think of it more like building stuff out of Lego without following any instructions.
skydhash 5 days ago [-]
> There's also no reason why you have to literally write everything yourself either.
> It's roughly equivalent to trying to discover all of our scientific knowledge yourself from scratch vs taking "for granted" the knowledge discovered by your forebears.
The author do have another config with all the bells and whistles. But Emacs does come with a lot of packages and tweaking them isn't that much work compared to building a full suite like Helm, especially with the awesome documentation system. Getting a v0.x of anything can be a matter of minutes. And then you wake up one day and you've built a whole OS for your workflows.
amake 5 days ago [-]
> The "why" is kinda sketchy
It seems pretty clear that the "why" is "because it's there"
alfiedotwtf 4 days ago [-]
> because it’s fun
Sounds good enough for me
jimbokun 5 days ago [-]
I’m not sure how you missed it, but the “why” was clearly a challenge to better learn and understand Emacs. And because it was fun.
bitwize 5 days ago [-]
You have to sign the FSF's CLA (and clear your contributions with your employer) to contribute to Emacs itself. To ship a separate package to ELPA you need not do this.
pkal 5 days ago [-]
A point of clarification: GNU ELPA (https://elpa.gnu.org/) is part of Emacs, and you have to sign the copyright assignment to submit packages an to contribute to packages. NonGNU ELPA (https://elpa.nongnu.org/) doesn't have this restriction.
hirvi74 5 days ago [-]
This might be a paragon of masochism. Though, I am not only beyond impressed. I am beyond jealous as well.
I've been using Emacs since one of professors/mentors converted me over a decade ago back when I was attending university. As the years have progressed, I have found myself reaching for Emacs less and less. I still maintain my config and use it fairly often. I cannot use Emacs at my employer either, so that doesn't help.
However, I have always wanted to do what the author has demonstrated. I would love to be liberated from the all package dependencies I currently have. I just do not have the time nor self-discipline to do something like this. Even if the functionality would be less than or equal parity with 3rd-party packages, I would prefer the Devil I know over the ones I don't.
NetOpWibby 5 days ago [-]
I’m always impressed by people who are hardcore EMacs or Vim devs, their setups are impressive af.
I’m a GUI guy though. As soon as I try delving in, I abort when I see things like “just type c-C dingle bob to do x thing.” I’m happy these people found something that works with their brains. I just want a GUI that works like what they use.
I recently saw a Zed fork stripped of AI stuff but there’s no binaries yet (you gotta compile and get an Apple dev account and I don’t care enough). Zed and Sublime Text are the closest to my stylistic sensibilities but I’m always on the lookout for something better.
If you’re one of these EMacs freaks who also love GUIs, sign me up to your app!
LiamPowell 5 days ago [-]
> I’m a GUI guy though. As soon as I try delving in, I abort when I see things like “just type c-C dingle bob to do x thing.” I’m happy these people found something that works with their brains. I just want a GUI that works like what they use.
You do have that somewhat with packages like which-key that will show you a menu of options every time you press a key. You then learn the keybinds that you use the most. You can also search for them by name and see the keybind like you do with VS Code etc..
Here's what doom-emacs looks like when I press space and then space-t:
Which-key is invaluable as a way to navigate a large key chord hierarchy. Great for learning mode-specific commands that live under C-c.
yoyohello13 5 days ago [-]
> I just want a GUI that works like what they use.
I don't think this is really possible. The thing that makes it special is that there are key binds for all the 100s of things you could want to do. So it becomes sort of like playing a instrument where you use your muscle memory instead of thinking specifically about the keys. If you make a bunch of menus and buttons to do the things it would be a mess and probably not very nice to use. Emacs actually has buttons and GUI controls for lots of the functionality, but it kind of sucks to use it that way.
These setups are impressive specifically because the creator has put in the time and effort to become an expert at using their editor. There is just no way to hand that over to someone else as-is without any investment from the recipient in skill development.
ngc6677 5 days ago [-]
A nice way to get quickly familiar with how to use emacs/(neo)vi(m), understand how keybindings work and how to uncover new ones, is to go through reading/practicing the built-in tutorial. It almost plays like games.
When opening a freshly installed emacs, there should be a "Emacs Tutorial" link that can be clicked; also the keyboard shortcut `C-h t` (which is «Control + `h`, then `t`»).
There is a similar feature in `neovim`, when opened type `:Tutor` (which is «`:` to open the command prompt, with command `Tutor`»).
deltarholamda 4 days ago [-]
>I abort when I see things like “just type c-C dingle bob to do x thing.”
I used nothing but emacs for several years (well, xemacs, but close enough), because I was using an old Thinkpad, and long-term use of the trackpoint gave me RSI in my finger. Being able to use nothing but the keyboard was nice.
Eventually I went back to BBEdit and have remained there. You can make it mostly keyboard oriented if you want, but sometimes using the mouse is easier/faster, and I have a lot of reps inside of BBEdit. It just seems more like home to me. A nice balance between GUI and keyboard-focussed IMO.
The binary release for Linux is a bit rough, there's an `install.sh` script in the repo which can install the tarball for you. For the next release there will be flatpaks, .deb and .rpm available.
mhd 5 days ago [-]
I'd say most people run Emacs in the GUI mode, not in a terminal. So these days, you're pretty much on the same level as most rivals.
Sadly, "these days" is a low bar. The days of consistent platform-specific "Human Interface Guidelines" are over, it's all just a browser wrapped in a top-level window or something that simulates that, with most interaction patterns being a cargo cult of how it's remembered from the 90s. So "GUI" means that some unique overlays can be drawn without a fixed width character grid and that you might get the original file requester now and then.
mark_l_watson 5 days ago [-]
I mostly run Emacs in a terminal, except I configure for two finger scroll on Mac trackpad and tap to move cursor. I also reduced the size of my .emacs by 60% in the last year.
thunfischbrot 5 days ago [-]
The Zed fork sounds interesting!
What was the Apple Dev account needed for? Previously I remember it was only needed for submitting apps to the App Store, not running Dev builds locally.
NetOpWibby 3 days ago [-]
Last I checked it was just to notarize the app but I went back to the fork to remember and now there are binaries! https://codeberg.org/GramEditor/gram
klibertp 4 days ago [-]
> I just want a GUI that works like what they use.
TL;DR: Emacs is a GUI app and has lots of GUI-related functionality, but it tends to be slightly neglected by the majority of users. You can easily build your ideal GUI using the provided building blocks; the problem is, you have to build it, since most other users are not interested in doing so.
Both Emacs and Vim/NeoVIM have GUIs. I can't even run my Emacs in a terminal without `-q` (omit user config) - I never feel the need, and my config would be much more complex if I tried to make it terminal-friendly.
You don't need baroque keybinds, either. Both Emacs and Vim have always had "Command Palette" - Alt+x in Emacs, : in Vim - and with a few plugins[1], you get fuzzy matching, inline docs, icons showing what type of command you're looking at, etc. Both editors also have GUI buttons and mode-specific (on top of generic) menus (including context menus on click). This provides unmatched discoverability of available functions - you can then bind them to any key combination you find easy to remember. You don't have to, though, since with a few other plugins (Orderless), the frequently used commands bubble to the top of the list.
There are two things Emacs handles a bit poorly: mouse and popups. The former stems from existing users largely ignoring the issue, but the hooks for clicks and even gestures are there. The latter is an unfortunate consequence of wanting TUI to remain first class. There is functionality for creating Emacs "frames" (GUI windows) with given dimensions and a specified position, but it's basically GUI-only. Things like auto-completion popups default to something that can be emulated in the terminal, with frame/window-based implementations provided as extensions. That means that you can have a pop-up with method names starting with a few characters you typed, you can even have another pop-up beside that with docs for a given method, but you generally won't get that doc displayed as rendered markdown (you can't display headers with a bigger font in a terminal). It's 100% social and not a technical limitation - if you accept that you're only going to use Emacs in a GUI, you can get an IntelliJ-level of mouse and popup handling... Though it takes some effort.
That's the real problem, I think. You need to craft many of those features yourself out of available functionality. And it's not even a matter of some (even obscure) configuration, you will need to write your own Lisp to get the most out of Emacs. That's much more of a pain point and a respectable reason for not wanting to touch it. Technically, though, Emacs is not anti-GUI, and there are many packages that make Emacs pretty. Less so with mouse-friendliness, unfortunately, but you can configure it into something half-decent without much effort.
The only environment I know of that is (at least) equally powerful and flexible, but which handles GUI better is GToolkit[2] (VisualWorks was nice before the license change; now it's impossible to use) - a Smalltalk-derived system that uses the host OS (Linux/Windows/Mac) GUI directly through Rust bindings. A step down from there, but still respectable, is Pharo and the browser/Electron. Other than that, you have pre-written GUIs that you can't really change beyond what the developers planned.
Hey celadevra_, author here. Thanks for submitting my post to HN, I really appreciate it.
Seeing it stay at #1 for a few hours while my blog server struggled with the requests was quite a joy :)
PS: Also, thanks to everyone who commented on it. While I can't reply to all of you, I'm doing my best to read everything. I'm glad to hear that the project resonates with so many people, whether philosophically, aesthetically, or as something partially useful.
celadevra_ 4 days ago [-]
I've used {GNU |X}Emacs intensively for over 20 years and never thought about doing a thorough study of many of the things it provides like you do in Emacs Solo. Your work is inspiring to me in showing me what dedication and thoughtfulness can achieve, even when it seemed at the beginning as trivial as one tending their own homestead. Many, many kudos.
qazxcvbnm 5 days ago [-]
The new Emacs features sound great! (We have native window management finally)
I wish we would someday be able to edit in xref too, wgrep having landed in Emacs 30 (especially since project.el grep goes to xref by default).
By the way, anyone more informed know about any work on getting a graphical browser to work on latest Emacs, now that webkit xwidgets is dead for Emacs 30+? (Have tried EAF; extremely buggy on Mac)
jharsman 5 days ago [-]
Emacs solo actually contains functionality for just that, the below snippet which allows exporting xref buffers to grep format by pressing 'E'. You can then use wgrep etc.
;; Makes any xref buffer "exportable" to a grep buffer with "E" so you can edit it with "e".
(defun emacs-solo/xref-to-grep-compilation ()
"Export the current Xref results to a grep-like buffer (Emacs 30+)."
(interactive)
(unless (derived-mode-p 'xref--xref-buffer-mode)
(user-error "Not in an Xref buffer"))
(let* ((items (and (boundp 'xref--fetcher)
(funcall xref--fetcher)))
(buf-name "*xref→grep*")
(grep-buf (get-buffer-create buf-name)))
(unless items
(user-error "No xref items found"))
(with-current-buffer grep-buf
(let ((inhibit-read-only t))
(erase-buffer)
(insert (format "-*- mode: grep; default-directory: %S -*-\n\n"
default-directory))
(dolist (item items)
(let* ((loc (xref-item-location item))
(file (xref-file-location-file loc))
(line (xref-file-location-line loc))
(summary (xref-item-summary item)))
(insert (format "%s:%d:%s\n" file line summary)))))
(grep-mode))
(pop-to-buffer grep-buf)))
(with-eval-after-load 'xref
(define-key xref--xref-buffer-mode-map (kbd "E")
#'emacs-solo/xref-to-grep-compilation))
qazxcvbnm 5 days ago [-]
My goodness, how so thoughtful Emacs Solo is!
lvass 5 days ago [-]
This is beautiful, incredibly sane, and awesome reference material. There's no way I'd use a 3500 lines init.el or most of the extras, but somehow I feel like a good chunk of the stuff here should be upstreamed if we one day consider it reasonable to change default behaviors in a major update.
otsaloma 4 days ago [-]
> Partly because I wanted my config to survive without breakage across Emacs releases. Partly because I was tired of dealing with package repositories, mirrors going down in the middle of the workday, native compilation hiccups, and the inevitable downtime when something changed somewhere upstream and my job suddenly became debugging my very long (at the time) config instead of doing actual work.
Picking on this detail, what I've found works nicely is that when a new major Emacs version flows into my Debian, I also update all packages to their latest versions and then freeze those versions until the next major Emacs release. And those versions are locked in my emacs.d git repo, so I have a reproducible Emacs at home and work both. There's a little iteration to adapt to changes in Emacs and packages, but after that, it's stable and reliable for a year or two.
I feel I can given up most packages I use for some hand rolled code (with a significant time investment, that is). There will be tradeoffs.
Every thing except magit. I can’t think of a better way to use git, and it’s one of the main reasons I’ve never survived my adventures in editor wilds for very long.
internet_points 5 days ago [-]
This was a beautiful article; the joy of tinkering just shines through everywhere :-) I'm glad Rahul did the work to upstream some of the changes, I hope some of the maintainers read his post and are inspired to change a few defaults too (with that init.el vs `lisp/` refactor it should be easier for them to see what wants changing). Maybe some of the packages might provide for inspiration too; I'd love to see vc-mode provide builtin gutter support, for example. And viper extensions sounds like something that should just be upstreamed. (Less so exchange rates and weather.) Emacs is so close to being quite good out-of-the-box.
yunnpp 5 days ago [-]
Is Eglot on par with emacs-lsp for C++? Specifically thinking about pointing it to a compile_commands.json and all of the usual C++ nonsense required for code navigation and autocomplete.
gpderetta 5 days ago [-]
Pretty much yes. I switched to eglot from emacs-lsp because of some frequent random errors ("document not added") that required me to frequently kill clangd; might be a PEBCAK problem, but went away with eglot.
Everything mostly worked out of the box.
Ferret7446 5 days ago [-]
The UX will be different and is a matter of preference. The performance depends solely on your LSP. So long as your LSP is the same and configured the same, it will give you the same results for navigation/completion.
internet_points 5 days ago [-]
I use it that way. It requires less setup than lsp-mode. Just try it – add `:disabled t` to your use-package lsp-mode, restart emacs and type `M-x eglot` in a C++ buffer.
kidsil 5 days ago [-]
Funny, this mirrors almost exactly a decision I made after about a year of struggling with ELPA packages breaking on me repeatedly.
I ended up cutting Emacs off from ELPA entirely, settled on a ~700-line init.el, and now use Emacs as a glorified Org-mode agenda keeper. It's been heavenly (especially with a dedicated monitor).
The one thing I'm still working out is syncing with calendars and email.
drob518 5 days ago [-]
Interesting. I use ELPA/MELPA all the time and find things pretty stable for my own uses. Surprisingly so, in fact. I honestly expected more hiccups. I wonder whether it’s differences between the packages that we use or the complexity of the configuration or what. Mostly I spend my time in Clojure mode with CIDER and Magit. I’m not trying to run email and calendar in Emacs.
jamespo 5 days ago [-]
Being able to sudo edit inside emacs via tramp is something I've only recently discovered and I've being using emacs for years...
ajstars 4 days ago [-]
The solo Emacs path is underrated for building deep understanding. Most people reach for a config framework immediately and end up with a system they can't debug. Starting from scratch forces you to actually understand what each piece does, even if it takes longer upfront.
timonoko 5 days ago [-]
I tried (setq backup-directory-alist '(("." . ".local/share/Trash/files/"))). It would have been fun if backup files were also Thunar Trash.
But too many problems. Even Grok, Gemini and Chatgpt were stunned.
CodeCompost 5 days ago [-]
Emacs is awesome but customizing it costs me way too much of my precious time.
drob518 5 days ago [-]
Yep, me too. That’s the eternal trade-off. I’m always pretty sure that there’s a specific Emacs function or mode that does exactly what I want, but I mostly can’t be bothered to find it beyond a quick guessing search via apropos (C-h a). I brute-force my way through a lot of tasks using keyboard macros that might otherwise be solved more elegantly if I had the time.
4 days ago [-]
pmontra 4 days ago [-]
Thank you. I finally looked into project.el and I started using C-x p f, C-x p b. It was already configured by default. Lazy me.
iJohnDoe 5 days ago [-]
This guy Emacs!
In all seriousness very impressive and cool. Great information and post.
bergheim 4 days ago [-]
Great stuff. Funny how that whole Ai thing is Ai generated:
No gptel, no ellama, just url-retrieve and some JSON parsing.
The no x no y just z is the new em dashes. And that will probably be true for about a week.
NetMageSCW 4 days ago [-]
Unjustified huge assumption by someone who has AI living free in their head incoming!
throwaway27448 5 days ago [-]
Why are we so bad at naming things? Modules and packages are so abstract I need to google what they mean relative to the development environment just to move forward.
InMice 5 days ago [-]
That's the beauty of open source
gyrgtyn 5 days ago [-]
The only reason I'm still using emacs is magit (and muscle memory). I could not make magit myself.
asymmetric 5 days ago [-]
For me it’s org-mode. Although now that I think of it, there’s a Neovim implementation I’ve been meaning to try.
fedreg 5 days ago [-]
super impressive!! Going to steal some of this lisp for sure
5 days ago [-]
coolcoder9520 5 days ago [-]
[flagged]
shevy-java 5 days ago [-]
Poor guy - stuck with lisp on an ancient operating system ...
And no - vim isn't any better either. I always felt that in
the emacs-versus-vim debate there were two losing sides.
Antibabelic 5 days ago [-]
Perhaps these poor guys possess a secret wealth beyond your wildest imagination. I wouldn't give up Emacs for anything.
vincent-manis 4 days ago [-]
I agree with you. Edlin forever!!!
gpderetta 5 days ago [-]
"a weapon from a more civilized age".
bananamogul 5 days ago [-]
If I was going to reimplement Emacs it wouldn't be with Lisp.
Is there some reason Lisp is superior to any other general-purpose programming language for text editing? I'm skeptical because to my knowledge, Emacs is the only major text editor written in Lisp.
Barrin92 5 days ago [-]
>Is there some reason Lisp is superior to any other general-purpose programming language for text editing?
purely for text editing? No. But that's not what distinguishes Emacs, it's famously very mediocre at it. The point of Emacs is to be a fully transparent, inspectable, dynamic and changeable environment. In spirit similar to Smalltalk systems like Pharo. And for that a Lisp is not the only choice but a very good one.
There's very few languages and environments that facilitate jumping into any place, making a change, compiling or evaluating a block of code or treating it as data and continuing seamlessly.
antiframe 4 days ago [-]
> But that's not what distinguishes Emacs, it's famously very mediocre at it.
I disagree. Every time I use another editor I lament missing features when it comes to editing text. Like most editors (vim excluded) have pretty lackluster undo, transpose, case altering, and text reflowing commands.
NetMageSCW 4 days ago [-]
An editor environment based on Smalltalk would be very interesting.
klibertp 4 days ago [-]
See GToolkit[1] - Lepiter is a bit like that. It's too notebook-y for my taste, but it lets you write and format text and embed any widget. It also uses a native GUI and is not a repackaged browser.
Did they do anything to fix the OpenSmalltalk VM lamentable keyboard input?
drob518 4 days ago [-]
Not specifically superior for text editing, but it has some specific capabilities that make it ideal for making an editing environment. Specifically, it’s great at incremental, dynamic loading of small code snippets. This allows development of Emacs code without having to recompile and restart all the time. In fact, the low-level core of Emacs (buffer manipulation code, regex execution, redisplay, etc.) is all in C. But then those C routines are strung together with Lisp to make up all the high level functionality. Having a dynamic, incremental language is really handy for that. Does it have to be Lisp? No, not necessarily. But Lisp is a great choice.
spudlyo 5 days ago [-]
It's a product of its time. In the mid 70s when Emacs was originally created, the MIT Lisp Machine Project had already been going for a few years, and Lisp was kind of a big deal at MIT's AI Lab, where it was created. When Stallman started GNU Emacs in '85 or so, he took lots of inspiration from Lisp and those systems.
You can think of Emacs as a kind of software Lisp machine with an emphasis on editing. Although that analogy only works well if you squint or if you don't know a lot about Lisp machines.
As someone who first learned Lisp through Emacs Lisp, I found it fun, well-documented, and powerful. Once you grok the basics of how the system is dynamically glued together, infinitely hackable, and self-documenting it's kind of mind-blowing.
internet_points 5 days ago [-]
The Lem editor[0] and LispWorks IDE's[1] are implemented in Common Lisp.
Still, the reason for choosing a language for whatever are always more social and path-dependent than technical (reason 1: initial developer of whatever really likes the language, reason 2: language is seen as hip within some crowd, reason 3 (later in the game): management feels language is safe). Technical reasons for choosing a language typically tend to be post-hoc rationalizations. (I mean, no sane person would choose Javascript for an editor based on technical reasons alone, yet here we are.)
As much as I love Common Lisp, it's dead. It has 2 orders of magnitude fewer packages in quicklisp than Emacs has in MELPA - and Emacs is an editor, not a general-purpose programming language. SBCL has a handful of devs and moves very slowly - nothing else does at all. Maybe LispWorks, but that's expensive.
CL is also held together - and held back, hugely - by the standard that won't ever be updated. It's good to have it, but there are major omissions (code walkers, MOP) that won't ever be fixed.
As it is now, Elisp is more practical as a scripting language than CL. The gap will only continue to grow. Right now, CL has an edge in parallelism - native threads and mutexes (with all the problems they entail) work there, while with Emacs, the only parallelism you can get is through separate processes. On the other hand, async/await-style concurrency works quite well in Emacs, while in CL you're basically a few macros away from raw promises, and the only real asynchrony is through a pool of threads executing callbacks, and it doesn't play well with conditions and restarts and some other advanced features (notably absent from Elisp).
I love CL, but right now it's aged considerably, lost many of its unique advantages, and has little chance of ever catching up. It's a shame, but using CL in 2026 is not a superpower anymore - it's just one of the similarly-valued propositions, competing with other dynamic languages, still providing a few unique advantages, but even those are being implemented in other languages fast.
beepbooptheory 5 days ago [-]
Lisp calls c in emacs. What would be a better language? The code-as-data, data-as-code paradigm fits nicely imo with everything-is-a-buffer. Things like global namespace, hooks, defadvice, would all feel very wrong in other interpreter, and yet seem to make sense in elisp.
sunng 5 days ago [-]
Emacs is like a minecraft of lisp expressions.
0xpgm 5 days ago [-]
A good reason is that Lisp has almost no syntax. So it can act as a neutral language that is easy to learn for developers from other languages.
bandrami 5 days ago [-]
Because it's very easy to generate lisp code. It's meant for metaprogramming
jimbokun 5 days ago [-]
But if you were implementing it in 1976 you would have.
pkal 5 days ago [-]
But in 1976 Emacs was implemented in TECO. In 1984 it was implemented in Lisp, because Multics Emacs _or_ EINE/ZWEI (Lisp Machine editors) were using Lisp as an extension language, which apparently has shown itself to be useful.
NetMageSCW 4 days ago [-]
Consider Lugaru Epsilon - an Emacs style editor that has a C based extension language.
jibal 5 days ago [-]
This article isn't about reimplementing emacs.
BTW emacs is written in C.
NetMageSCW 4 days ago [-]
No, emacs is pretty much written in elisp. There is a core runtime written in C, but that exists pretty much to run elisp code.
jibal 4 days ago [-]
P.S. As for the naysayer: The C code does a lot more than run elisp. e.g., memory management/GC, display and I/O, primitives/built-in functions/subrs, system services.
Even if you interpret emacs strictly as an interpreter of elisp, that interpreter is written in C, not elisp.
If you removed all elisp from the emacs distribution, you would still have an extensible windowed text editor. And you could add any desired functionality by writing elisp. Take C code away and you've got nothing functional.
It's crazy to me how out of the box when you edit nginx file at /etc/nginx/sites-enabled/foo it creates another file foo~ there and nginx tries to load that too
When I tried to ask emacs reddit community they started attacking me for changing the default that only I need and fits everyone perfectly.
Still can't believe I'm the only one finding that default amazingly bad.
Using hidden files is a stronger convention, e.g. .foo.swp or .foo~.
But nginx's sites-enabled also doesn't filter those.
It's a very simple mechanism that assumes what you put in that directory is a website configuration.
Adding backup files here and there is considered spam, no matter how old it is.
It's the second thing I fix in either Vim or Emacs: Put backup files in a central location. (The first is proper indentation/spacing rules.)
Emacs does foo~ by default, not ~foo.
In either case, you're not really supposed to edit files in sites-enabled. That directory is expected to contain symlinks to files in sites-available. I'm not going to say with any certainty that one of the reasons for this indeed is that the pattern (which was used by apache as well - and perhaps other things before it) protects against accidentally reading backup files, but it's not impossible.
So there's definitely a case of holding it wrong if you end up with backup files in that directory.
Perhaps not a standard, but you yourself admit it's the default behavior.
Though I agree that the simple mechanism acts ... er,... simply, shouldn't it be at the very least aware of the default behavior of common editors?
Just that the message does not contribute to the conversation.
Neither does this one.
I won't comment further, as we are now off topic (thanks to you).
That said, Nginx is also wrong and shouldn't do that.
Without this I had to be careful not to acciddentally commit stuff like ".#filename.txt".
First thing I do any time I install emacs.
Note that tramp will kvetch if you do this, but it still works fine.
(setq make-backup-files nil)
The fact it can do multi-hop edits is far too much power for us mere mortals.
nvim scp://remotemachine/.config/emacs/init.el
For the same reason you can use sshfs, sftp, and rsync with multi-hop. Gotta love openssh!
- I already have tmux launched, if ssh drops – I can continue
- I don't have to match windows to ssh sessions -- just have them in my tmux
Tramp runs in your local Emacs and edits files remotely. It can also launch processes remotely and keep track of them.
(but I still think this is on nginx more than emacs - unless they really mean foo~ and not .foo~ )
There are a ton of Emacs users, and it's doesn't make much sense to talk about them as a group like that, no more than if I were to say, "The list of things Windows users don't get..."
You can change your own defaults quite easily!
Changing the default setup with emacs that has been shipping for > 30 years is tough.
Getting nginx to ignore a well established pattern by a well established editor seems equally sensible and perhaps more doable. Yes?
I disagree about "tough". Emacs has changed for the better in new releases quite drastically in the last years in my experience.
But it's easy to disable or have them created somewhere else, which is more than you can say for most software lately.
There's also a docker package for managing containers - similar concept and UI to magit, but for managing Docker. Not as life changing as magit, but convenient.
Anyway, the problem with changing the default after all this time is that everybody would want the new default to be different, and changing it now would meaning breaking things for long time users who depend on the current default. And TBH if you're setting up a container and installing Emacs, it's very little extra work to copy over a .emacs file that fixes everything the way you like.
using the same directory drastically reduces the amount of assumptions about your system's permissions and your own installation (or lack thereof)
old school *nix editors typically do something like emacs and vi typically do, whereas old WinDOS/Mac single-user systems would have an installation file and a cache system-wide, and post NT and OS-X they have roughly the same but in a centralised user directory that is not system-wide, but is located as if it were (different evolution path)
[1]: https://gist.github.com/imiric/812398910c59cf00ab43d9172fe42...
This reminds me of a story from a past job. I have to get it out of my system.
There was this bearded sysadmin guy who was very proud of his "15 years of experience", and was quick to scold us new employees for every little thing he could.
He used vim, and every now and then would say that it's a good editor, but kinda "unstable". Crashed a lot, he said.
You probably know where this is going.
One day, one of us sat next to him and discovered many suspended vim jobs in his shell (this was the kind of guy that doesn't power off his computer).
He was fat-fingering C-z all the time, and has never heard of job control - bg, fg, etc.
15 years of experience.
I know you might prefer to run a shell on emacs (or vim) but something only the full terminal can do what you need it to do
There's always `M-x term` for a full terminal.
Also, with LLMs driving so much of current development it potentially makes Emacs even more competitive relative to modern IDEs. Development can be driven primarily by an agent like Claude Code from the command line, then navigating and tweaking the code, handling Git commits, etc with Emacs.
I imagine an LLM would be very good at writing Elisp to leverage EMacs’ strong core functionality to make Emacs work exactly how you want. This author managed to do it by hand, but I imagine someone starting now with an LLM could get there much faster.
Yes, they are pretty good. I have set up GPTel (an excellent Emacs package for interacting with LLMs) with some tools allowing it to run Elisp, inspect files (Elisp functions know what file they were defined in, so it's easy to find stuff) and read Emacs documentation. LLMs use this to good effect, and iterate on my config very nicely.
Claude has been really good at writing and debugging the code for me.
Emacs is highly customisable. There's not really a hard difference between "configuration" and "extension". Whereas with e.g. VSCode, very few people would write their own extensions. -- So it's a good point that with LLMs, the barrier to customise Emacs to exactly how you want it is even lower.
I'd also argue that since practically everything in Emacs is text (as opposed to a rich GUI interface), Emacs itself ought to make for a nice interface to LLM functionality.
This resonates with me so hard. I'm not a "no external packages" purist, but there are a number of pieces of functionality that I wrote for myself because there wasn't anything quite like what I wanted.
One example is a function to expand the region (selection) to any arbitrary set of pairing delimiters that I define in a defvar (parens, quotes, brackets, or I can can supply a custom left/right regex for matching). Then, when I execute the function, it waits for a second keypress, which is the trigger key I've defined for that matching pair, and it will expand the region to the left and the right until it meets the applicable delimiter.
Repeating the same key presses results in selecting the left and right delimiters themselves, and another repeat will extend to the next set of matching delimiters, and so on.
Even though I use a treesitter-based expand-region plug-in, my custom function is still invaluable for when I want to jump past a series of valid treesitter object expansions, or when certain text objects are just not defined in treesitter.
Some of the helpful custom expansions I have defined are:
"w" to select what Vim considers a lowercase-w word
Space to select what Vim considers an uppercase-W word
"$" to select ${...}-style expressions
"/" to select everything between forward slashes
"*" to select between asterisks (useful when editing markdown)
It's really an invaluable function for me, personally, but I always talk myself out of trying to open-source it because it has some gotchas and limitations, and I just don't want to be on the hook for trying to make everyone who uses it happy.
?!? Wtf does this mean and how did vi come up
Because you people are cracking your eggs from the wrong end!
That's because both ends are wrong. Eggs should be cracked from the side.
Can't believe this still needs to be said on this forum in 2026.
And we still don't have a usable editor outside of emacs
There's also no reason why you have to literally write everything yourself either. You can find open source licensed packages, read them to understand them, and then copy them into your config. Doing everything from scratch is a waste of time unless you enjoy the process (in which case go nuts).
It's roughly equivalent to trying to discover all of our scientific knowledge yourself from scratch vs taking "for granted" the knowledge discovered by your forebears. There is no shame or disadvantage in doing so.
Also, a critical objection:
> Writing your own packages is the best way to learn Elisp
Absolutely not. Reading a language is crucial. If all you do is write, you will pigeonhole into weird practices and generally fail to improve. Only by reading stuff written by others can you learn, as you're exposed to what other people do right and wrong, both of which will be different from you.
Of course, writing your own packages is also necessary, but not sufficient alone.
I don't think the post implied that this package writing activity was a write-only activity where reading and learning is strictly forbidden.
> You can find open source licensed packages, read them to understand them, and then copy them into your config. Doing everything from scratch is a waste of time unless you enjoy the process (in which case go nuts).
The post clearly indicates the relatively large set of open source packages they looked at and understood before doing their own packages. The author graciously acknowledges them and their influence on the work:
"Emacs Solo doesn't install external packages, it is deeply influenced by them. diff-hl, ace-window, olivetti, doom-modeline, exec-path-from-shell, eldoc-box, rainbow-delimiters, sudo-edit, and many others showed me what was possible and set the bar for what a good Emacs experience looks like. Where specific credit is due, it's noted in the source code itself."
I think of it more like building stuff out of Lego without following any instructions.
> It's roughly equivalent to trying to discover all of our scientific knowledge yourself from scratch vs taking "for granted" the knowledge discovered by your forebears.
The author do have another config with all the bells and whistles. But Emacs does come with a lot of packages and tweaking them isn't that much work compared to building a full suite like Helm, especially with the awesome documentation system. Getting a v0.x of anything can be a matter of minutes. And then you wake up one day and you've built a whole OS for your workflows.
It seems pretty clear that the "why" is "because it's there"
Sounds good enough for me
I've been using Emacs since one of professors/mentors converted me over a decade ago back when I was attending university. As the years have progressed, I have found myself reaching for Emacs less and less. I still maintain my config and use it fairly often. I cannot use Emacs at my employer either, so that doesn't help.
However, I have always wanted to do what the author has demonstrated. I would love to be liberated from the all package dependencies I currently have. I just do not have the time nor self-discipline to do something like this. Even if the functionality would be less than or equal parity with 3rd-party packages, I would prefer the Devil I know over the ones I don't.
I’m a GUI guy though. As soon as I try delving in, I abort when I see things like “just type c-C dingle bob to do x thing.” I’m happy these people found something that works with their brains. I just want a GUI that works like what they use.
I recently saw a Zed fork stripped of AI stuff but there’s no binaries yet (you gotta compile and get an Apple dev account and I don’t care enough). Zed and Sublime Text are the closest to my stylistic sensibilities but I’m always on the lookout for something better.
If you’re one of these EMacs freaks who also love GUIs, sign me up to your app!
You do have that somewhat with packages like which-key that will show you a menu of options every time you press a key. You then learn the keybinds that you use the most. You can also search for them by name and see the keybind like you do with VS Code etc..
Here's what doom-emacs looks like when I press space and then space-t:
https://files.catbox.moe/szfcif.png
https://files.catbox.moe/2kgrai.png
I don't think this is really possible. The thing that makes it special is that there are key binds for all the 100s of things you could want to do. So it becomes sort of like playing a instrument where you use your muscle memory instead of thinking specifically about the keys. If you make a bunch of menus and buttons to do the things it would be a mess and probably not very nice to use. Emacs actually has buttons and GUI controls for lots of the functionality, but it kind of sucks to use it that way.
These setups are impressive specifically because the creator has put in the time and effort to become an expert at using their editor. There is just no way to hand that over to someone else as-is without any investment from the recipient in skill development.
When opening a freshly installed emacs, there should be a "Emacs Tutorial" link that can be clicked; also the keyboard shortcut `C-h t` (which is «Control + `h`, then `t`»).
There is a similar feature in `neovim`, when opened type `:Tutor` (which is «`:` to open the command prompt, with command `Tutor`»).
I used nothing but emacs for several years (well, xemacs, but close enough), because I was using an old Thinkpad, and long-term use of the trackpoint gave me RSI in my finger. Being able to use nothing but the keyboard was nice.
Eventually I went back to BBEdit and have remained there. You can make it mostly keyboard oriented if you want, but sometimes using the mouse is easier/faster, and I have a lot of reps inside of BBEdit. It just seems more like home to me. A nice balance between GUI and keyboard-focussed IMO.
https://codeberg.org/GramEditor/gram/releases/tag/1.0.0
The binary release for Linux is a bit rough, there's an `install.sh` script in the repo which can install the tarball for you. For the next release there will be flatpaks, .deb and .rpm available.
Sadly, "these days" is a low bar. The days of consistent platform-specific "Human Interface Guidelines" are over, it's all just a browser wrapped in a top-level window or something that simulates that, with most interaction patterns being a cargo cult of how it's remembered from the 90s. So "GUI" means that some unique overlays can be drawn without a fixed width character grid and that you might get the original file requester now and then.
What was the Apple Dev account needed for? Previously I remember it was only needed for submitting apps to the App Store, not running Dev builds locally.
TL;DR: Emacs is a GUI app and has lots of GUI-related functionality, but it tends to be slightly neglected by the majority of users. You can easily build your ideal GUI using the provided building blocks; the problem is, you have to build it, since most other users are not interested in doing so.
Both Emacs and Vim/NeoVIM have GUIs. I can't even run my Emacs in a terminal without `-q` (omit user config) - I never feel the need, and my config would be much more complex if I tried to make it terminal-friendly.
You don't need baroque keybinds, either. Both Emacs and Vim have always had "Command Palette" - Alt+x in Emacs, : in Vim - and with a few plugins[1], you get fuzzy matching, inline docs, icons showing what type of command you're looking at, etc. Both editors also have GUI buttons and mode-specific (on top of generic) menus (including context menus on click). This provides unmatched discoverability of available functions - you can then bind them to any key combination you find easy to remember. You don't have to, though, since with a few other plugins (Orderless), the frequently used commands bubble to the top of the list.
There are two things Emacs handles a bit poorly: mouse and popups. The former stems from existing users largely ignoring the issue, but the hooks for clicks and even gestures are there. The latter is an unfortunate consequence of wanting TUI to remain first class. There is functionality for creating Emacs "frames" (GUI windows) with given dimensions and a specified position, but it's basically GUI-only. Things like auto-completion popups default to something that can be emulated in the terminal, with frame/window-based implementations provided as extensions. That means that you can have a pop-up with method names starting with a few characters you typed, you can even have another pop-up beside that with docs for a given method, but you generally won't get that doc displayed as rendered markdown (you can't display headers with a bigger font in a terminal). It's 100% social and not a technical limitation - if you accept that you're only going to use Emacs in a GUI, you can get an IntelliJ-level of mouse and popup handling... Though it takes some effort.
That's the real problem, I think. You need to craft many of those features yourself out of available functionality. And it's not even a matter of some (even obscure) configuration, you will need to write your own Lisp to get the most out of Emacs. That's much more of a pain point and a respectable reason for not wanting to touch it. Technically, though, Emacs is not anti-GUI, and there are many packages that make Emacs pretty. Less so with mouse-friendliness, unfortunately, but you can configure it into something half-decent without much effort.
The only environment I know of that is (at least) equally powerful and flexible, but which handles GUI better is GToolkit[2] (VisualWorks was nice before the license change; now it's impossible to use) - a Smalltalk-derived system that uses the host OS (Linux/Windows/Mac) GUI directly through Rust bindings. A step down from there, but still respectable, is Pharo and the browser/Electron. Other than that, you have pre-written GUIs that you can't really change beyond what the developers planned.
[1] Vertico + Marginalia + Embark in my case
[2] https://gtoolkit.com/
Seeing it stay at #1 for a few hours while my blog server struggled with the requests was quite a joy :)
PS: Also, thanks to everyone who commented on it. While I can't reply to all of you, I'm doing my best to read everything. I'm glad to hear that the project resonates with so many people, whether philosophically, aesthetically, or as something partially useful.
I wish we would someday be able to edit in xref too, wgrep having landed in Emacs 30 (especially since project.el grep goes to xref by default).
By the way, anyone more informed know about any work on getting a graphical browser to work on latest Emacs, now that webkit xwidgets is dead for Emacs 30+? (Have tried EAF; extremely buggy on Mac)
Picking on this detail, what I've found works nicely is that when a new major Emacs version flows into my Debian, I also update all packages to their latest versions and then freeze those versions until the next major Emacs release. And those versions are locked in my emacs.d git repo, so I have a reproducible Emacs at home and work both. There's a little iteration to adapt to changes in Emacs and packages, but after that, it's stable and reliable for a year or two.
https://github.com/radian-software/straight.el
Every thing except magit. I can’t think of a better way to use git, and it’s one of the main reasons I’ve never survived my adventures in editor wilds for very long.
Everything mostly worked out of the box.
I ended up cutting Emacs off from ELPA entirely, settled on a ~700-line init.el, and now use Emacs as a glorified Org-mode agenda keeper. It's been heavenly (especially with a dedicated monitor).
The one thing I'm still working out is syncing with calendars and email.
But too many problems. Even Grok, Gemini and Chatgpt were stunned.
In all seriousness very impressive and cool. Great information and post.
No gptel, no ellama, just url-retrieve and some JSON parsing.
The no x no y just z is the new em dashes. And that will probably be true for about a week.
And no - vim isn't any better either. I always felt that in the emacs-versus-vim debate there were two losing sides.
Is there some reason Lisp is superior to any other general-purpose programming language for text editing? I'm skeptical because to my knowledge, Emacs is the only major text editor written in Lisp.
purely for text editing? No. But that's not what distinguishes Emacs, it's famously very mediocre at it. The point of Emacs is to be a fully transparent, inspectable, dynamic and changeable environment. In spirit similar to Smalltalk systems like Pharo. And for that a Lisp is not the only choice but a very good one.
There's very few languages and environments that facilitate jumping into any place, making a change, compiling or evaluating a block of code or treating it as data and continuing seamlessly.
I disagree. Every time I use another editor I lament missing features when it comes to editing text. Like most editors (vim excluded) have pretty lackluster undo, transpose, case altering, and text reflowing commands.
[1] https://gtoolkit.com/
You can think of Emacs as a kind of software Lisp machine with an emphasis on editing. Although that analogy only works well if you squint or if you don't know a lot about Lisp machines.
As someone who first learned Lisp through Emacs Lisp, I found it fun, well-documented, and powerful. Once you grok the basics of how the system is dynamically glued together, infinitely hackable, and self-documenting it's kind of mind-blowing.
Still, the reason for choosing a language for whatever are always more social and path-dependent than technical (reason 1: initial developer of whatever really likes the language, reason 2: language is seen as hip within some crowd, reason 3 (later in the game): management feels language is safe). Technical reasons for choosing a language typically tend to be post-hoc rationalizations. (I mean, no sane person would choose Javascript for an editor based on technical reasons alone, yet here we are.)
[0] https://lem-project.github.io/ [1] https://www.lispworks.com/products/lispworks.html
CL is also held together - and held back, hugely - by the standard that won't ever be updated. It's good to have it, but there are major omissions (code walkers, MOP) that won't ever be fixed.
As it is now, Elisp is more practical as a scripting language than CL. The gap will only continue to grow. Right now, CL has an edge in parallelism - native threads and mutexes (with all the problems they entail) work there, while with Emacs, the only parallelism you can get is through separate processes. On the other hand, async/await-style concurrency works quite well in Emacs, while in CL you're basically a few macros away from raw promises, and the only real asynchrony is through a pool of threads executing callbacks, and it doesn't play well with conditions and restarts and some other advanced features (notably absent from Elisp).
I love CL, but right now it's aged considerably, lost many of its unique advantages, and has little chance of ever catching up. It's a shame, but using CL in 2026 is not a superpower anymore - it's just one of the similarly-valued propositions, competing with other dynamic languages, still providing a few unique advantages, but even those are being implemented in other languages fast.
BTW emacs is written in C.
Even if you interpret emacs strictly as an interpreter of elisp, that interpreter is written in C, not elisp.
If you removed all elisp from the emacs distribution, you would still have an extensible windowed text editor. And you could add any desired functionality by writing elisp. Take C code away and you've got nothing functional.