Two Years of Emacs Solo
rahuljuliato.com177 points by celadevra_ 7 hours ago
177 points by celadevra_ 7 hours 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.
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.
Yes I’ve added this to hundreds of containers and vms at this point
(setq make-backup-files nil)
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.
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)
This was one of the very first things I added to my config over a decade ago:
(setq backup-directory-alist '(("." . ".~")))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.
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.
> 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."
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.
> The "why" is kinda sketchy
It seems pretty clear that the "why" is "because it's there"
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.
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.
> 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.
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.
> 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.
> "w" to select what Vim considers a lowercase-w word
?!? Wtf does this mean and how did vi come up
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
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?
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)
The 'when it breaks, I know exactly where to look' part really resonates. It’s the same reason I’m a big fan of deterministic systems over probabilistic ones. There’s a specific kind of professional peace of mind that comes from owning the entire execution graph of your own tools, whether it’s a text editor config or a security middleware for AI agents. It's not about being a purist; it's about being the master of your own stack.
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!
> 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:
> 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.
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.
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.
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.
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.
But if you were implementing it in 1976 you would have.
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.
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.
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.
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.
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.
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.
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.
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.
The only reason I'm still using emacs is magit (and muscle memory). I could not make magit myself.
super impressive!! Going to steal some of this lisp for sure
This guy Emacs!
In all seriousness very impressive and cool. Great information and post.
