All the other comments in this thread talk about emacs instability when that hasn't been the case for me. I'm on doom emacs, update once in a while, and everything mostly just works other than some color scheme weirdness I had to fix.
Some of it is the maintainer shielding us from the breaking changes, but I also think the ecosystem is more slow moving than other editors which helps. The editor is older than most devs after all.
arikrahman 2 days ago [-]
I find that Emacs is actually the first mover on prime technologies. Just look at gptel and org-mode. Nothing else really even comes close. The reason some odd names exist like yank and kill or kill chain is because Emacs was the first and didn't have anything else to use as reference.
rpdillon 1 days ago [-]
Kill chain is a military term relating to the sequence of events that lead up to the actual attack.
You're probably thinking of kill ring, which I always thought was a neat term.
wglb 1 days ago [-]
It's also used in security defense, where there is a search for how to stop the many steps of attack.
imglorp 1 days ago [-]
That's right teco/emacs pre-dates xerox gypsy, which coined cut/copy/paste.
db48x 1 days ago [-]
Technically Kill and Yank came from TECO, which is an entirely different visual editor that predates Emacs.
royal__ 2 days ago [-]
Can you explain more what's wrong with the Neovim ecosystem? I just switched from Doom Emacs to Neovim and my impression of Neovim has been much better. (I get that Emacs has a much more powerful backbone, I just realized that I didn't really need that power; I just want a good text editor)
iLemming 1 days ago [-]
> what's wrong with the Neovim ecosystem
Nothing's wrong with it. It's just incomparable categorically. Just like you can't really equate a photo-editor and the web-browser. Sure, there's a way to do photo editing in the browser, still will be weird to compare them.
> Neovim has been much better
In what sense? Emacs is a Lisp interpreter with a text editor embedded in it - one can fully emulate Neovim features in it, the opposite is hardly possible - you can bolt Lisp interpreter on top of Neovim, but it won't be the same.
> I just want a good text editor
Is that implying Emacs doesn't have "a good one"? You probably just have not discovered some mind-blowing features of the editor. It is hands down the best-known machine ever designed to deal with plain text, nothing even comes close. Indirect buffers alone are such a brilliant idea, I have zero clue how people ever exposed to that power would willingly abandon it. I get it though, building a text-manipulating theater orchestrated by Lisp is not for everyone. Unfortunately, most newcomers get attracted to Emacs hearing "how powerful an editor it is", without ever learning what exactly makes it as such.
royal__ 22 hours ago [-]
That all makes sense. I wasn't trying to attack Emacs or defend Neovim, for the record. I liked Emacs and didn't have any problems with it (except some window jankiness). I was mostly just curious about the ecosystem.
The big reason I switched is because a lot of the big features of Emacs (org mode, magit, "living" in Emacs, advanced text manipulation, the extreme extensibility of the software) were things that sound really amazing on paper, but in practice I just don't really need/use/care about, and that's just my preferences. But once again, Emacs is cool and I totally respect what it can do.
iLemming 16 hours ago [-]
Missing the point - it's not about "attacking/defending" - Emacs and Vim just can't be compared categorically, the core of their design is about two dissimilar, unrelated concepts. Vim's augmentation of modality is absolutely brilliant, beautiful model, enormously practical idea. Emacs rooted in another incredible, powerful idea - practical symbolic notation for lambda calculus. Comparing them plainly from their "text editor" aspect is wrong - it creates wrong perception of they are about.
It's almost invariably about the trade-offs, without knowing what they are and how to navigate them would remain a highly debatable topic.
You have fixated on a single (albeit voluminous) aspect of things to make a choice. But there are dozens of other things we can drop there and steer away from Emacs with wrong conclusions, e.g. Emacs has mail client capabilities, and for anyone unfamiliar with Lisp, it might be obvious - more specialized email apps would look far more capable. But for an experienced Lisper, no specialized app would ever suffice. Particularly because Lisp allows them to adapt things with extreme precision, specifically for their use cases.
> The big reason I switched
You have switched (as it seems) without even understanding what it was about. It's not about Org, Magit, or any other "features" of Emacs. The main idea is and always was the Lisp interpreter. For someone like me (staunch Lisper) Magit is not some "packaged", ready-to-use piece of software, it's a set of libraries I can use. I can easily incorporate just about any Magit function into my workflow directly. I don't have to submit patches, I don't have to ask anyone's permission, I don't have to guess - the source code is given, I don't even have to save my experiments anywhere - I can just start typing Elisp code in my scratch buffer and eval things in place. Similarly - I use Org-mode for a bunch of things that may sound absolutely unrelated - I consume HN, Reddit, Jira, GitHub, Slack and other content in org-mode derived buffers. Why? Again, because of bunch of APIs, functions and commands that Org provides. I can for example easily retrieve any HN thread and extract all the URLs people posted in comments, and inspect each in-place - takes me a keystroke. Or I can send the text to an LLM - without ever copying and pasting, without context switching, without losing focus. No other [popular] piece of software ever granted me such enormous power and liberation.
I am absolutely so grateful to my younger self for forcing me to grok Emacs and Lisp, and I will never understand the sentiment and the "reasoning" of people moving away from it (after being exposed to its absolute supremacy over plain text). Realistically, there's never switching away from Emacs for me, that, unless a better Lisp engine emerges at some point. And btw. I am a die-hard Vimmer. I use vim motions everywhere - system wide. They permeate my editors/IDEs, web browsers, terminals, and yes, even Emacs. And I use Neovim as well - it works well when I need to reach for it - like I said: it's not a comparison.
JadeNB 1 days ago [-]
> In what sense? Emacs is a Lisp interpreter with a text editor embedded in it - one can fully emulate Neovim features in it, the opposite is hardly possible - you can bolt Lisp interpreter on top of Neovim, but it won't be the same.
Unless this is specifically what you want to do with Neovim, in which case you'll probably just use Emacs anyway, Neovim's inability to do this is probably not a strike against it. As royal__ says (https://news.ycombinator.com/item?id=48537120), they are just interested in a good text editor, not in raw computational power.
aktau 1 days ago [-]
I think Neovim itself has been stabilizing quite a bit in terms of upgrade breakage.
A common reason for breakage is/was:
- Neovim changes some API (deprecating, ...).
- User upgrades Neovim and theres some incompability, OR user upgrade plugin and that plugin assumes a much newer version of Neovim. (I've often seen Neovim plugins "mandate" either the latest stable Neovim or even HEAD).
But:
1. Neovim has been including some popular plugins (or at least their functionality domain) in the past few years. This obviates the need for plugin-for-$THING, and reduces breakage.
2. ISTM that the pace of (new) plugin development in the Neovim-sphere has slowed down.
The latest example of #1 is vim.pack, which is a plugin manager similar to vim-plug, mini.deps (vim.pack is based on mini.deps), lazy et cetera.
I can remember removing vim-commentary (from tpope) a while ago because Neovim included something like it in the main distribution. Granted, that specific plugin never broke because it uses the stable viml API.
QwenGlazer9000 1 days ago [-]
Yeah the lack of basic features in core meant core functionality was forced to use plugins with varying levels of documentation and commitments to stability (in some cases sending breaking changes before the supported neovim version even reached the arch repos). I'm glad to see neovim is improving in that aspect.
lycopodiopsida 1 days ago [-]
I think a big difference is that in the end emacs often makes a call and adopts one of the very popular packages to the core - eglot, modus-themes, use-package - there are certainly more, and more will come. It may not make everyone happy, but is sets the baseline - e.g., I am using eglot as package manager, but I wrap it into use-package commands for compatibility reasons.
No such thing exist in neovim (or at least in times when I was using it), so that churn never ends. Also I find, that neovim ecosystem is concentrated on one (very productive) developer in an unhealthy manner - folke often takes time off and half the packages one uses stands still.
But in the end, while I like neovim, I also find that emacs ecosystem has better ideas - which-key, embark do not stop to amuse me (I will not comment on whether it is a good thing for a text editor). I also do not like lua and actively dislike the experience of debugging and configuring neovim with it (maybe less of an issue with LLM these days).
In my experience, running in a terminal absolutely adds a bunch of rendering/performance issues and all kind of surprising failures with hotkeys.
maleldil 1 days ago [-]
> emacs often makes a call and adopts one of the very popular packages to the core
> No such thing exist in neovim
neovim has been doing that too. Plugin manager (vim.pack), treesitter stuff, LSP management, completion, comments, etc.
> which-key
neovim also has this.
> neovim ecosystem is concentrated on one (very productive) developer in an unhealthy manner
folke has nice stuff, but I find a lot of it is largely unnecessary and bloated. The only thing I use is his which-key, and there are alternatives, such as mini.clue.
rjzzleep 2 days ago [-]
LSPs keep getting reimplemented, package managers keep getting reimplemented. It's a bit like the react version of text editors.
I used it more than I use emacs, but I agree with the assessment of doom emacs vs neovim.
maleldil 1 days ago [-]
neovim core has most of what you need for LSPs. The only thing missing is server-specific configuration (e.g. binary name, flags), which you can copy from nvim-lspconfig or write yourself. There's also a native package manager in the core.
QwenGlazer9000 1 days ago [-]
It literally wasn't the case until relatively recently. It's an improvement in stability for the future, but the fact that before we had plug, then lazy, then finally we now have a built in one doesn't support the case necessarily the neovim ecosystem has a lot of churn.
I hope with these new built in alternatives that will change.
zelphirkalt 1 days ago [-]
To be fair, there are also tons of ways to manage packages in Emacs.
sph 1 days ago [-]
Neovim suffers from the Javascript kids mode of development. Constant change, constant churn, the mirage of stability always behind the corner, you always require third-party packages for functionality that should be core, completely erasing the Lindy effect of vim proper.
It’s a bit sad Neovim has stolen the thunder from the original work of Moolenaar & co. My guess is that neovim will splinter itself down the line further again once lua stops being attractive, while vim & Emacs will keep chugging along for another half century.
maleldil 1 days ago [-]
When did you last look at the neovim ecosystem? Because what you describe is the opposite of what's happened recently. The core has been getting more stable over time, with fewer breakages, and more essential functionality has been added, such as LSP support, completion, and a package manager, with plans to add more.
gsinclair 1 days ago [-]
That’s a serious misreading of the NeoVim ecosystem, and I’d bet good money against your predictions coming true.
QwenGlazer9000 1 days ago [-]
I've been seeing improvements lately other than the treesitter debacle, but this was literally the case 1 year ago.
Barrin92 14 hours ago [-]
>wrong with the Neovim ecosystem?
It's like a willful exercise in ignoring systems thinking. With Emacs every package tends to be designed with Emacs itself in mind, packages like consult, vertico, marginalia etc all built on Emacs' facilities improving not just the package itself but the overall experience of using Emacs, intentionally so.
The Neovim ecosystem is a bit like a dozen architects each designing a room in a house with total disregard for the layout of the house. A very common experience I had, and I never even used many plugins, was that when something was updated often something else would break. An update in the completion engine would cause some weird quirk with the lsp backend, etc.
Alien1Being 2 days ago [-]
I use both Emacs ( have used it for decades ) and began using Neovim recently.
Neovim seems fairly reasonable.
Using the LazyVim distribution of Neovim and it works quite well for my purposes.
QwenGlazer9000 1 days ago [-]
Distros help a lot shielding you from the churn, but lazyvim is maintained by folke who I hear loves breaking changes. Back when I used lazyvim I remember people complaining that he swapped out some major component randomly, I think it was auto complete.
Respect where it's due to folke, he's been pushing the neovim ecosystem forward incredibly fast. The bleeding edge just ain't everyone's style though.
quertyrecord74 1 days ago [-]
Use borg package. You'll get rock solid emacs. Worth the effort.
Seems worth a look, simply because it’s from the magit author.
cvdub 1 days ago [-]
Don’t think stuff like borg is necessary now that Emacs has built in support for installing packages from git repos (use-package :vc)
shevy-java 2 days ago [-]
The irony is that the vim camp can use just the same "argument" here about emacs. So that is a weird comparison to want to make here.
> The editor is older than most devs after all.
Well, being old does not automatically mean better. Peak human physical performance typically happens, with some exceptions (Justin Gatlin, if we ignore the use of enhancement drugs) in younger years; see Usain Bolt's fastest time achieved when he was young (23 years, in 2009). For mental tasks it is not so limited, but for physical peaks it is often in the younger years. For some software projects it also is the case that older age means more code, which in turn automatically mean smore bugs, all other things being equal. I am not necessarily questioning as to whether emacs has more bugs; my point is that the comparison/analogy does not work as means of quality assessment.
sph 1 days ago [-]
The evidence of younger code being better than old one doesn’t pass the smell test, and it’s hard to prove in a nascent field of technology where the oldest piece of software in continuous use has barely reached middle age.
You just cannot compare software robustness to human lifespan. Does software need 3 years at the bare minimum to be self-sufficient? Does it become argumentative and crashes a lot after 13-14 years?
weinzierl 2 days ago [-]
If you look at the output of mathematicians and their biggest discoveries it suggests that it is similarly limited for mental tasks.
kensai 2 days ago [-]
Probably this category of mental tasks. For politicians it's the other way around. Prolly you need to have some 'elder statesman' skills as well as wisdom to achieve greatness. Deng Xiaoping (https://en.wikipedia.org/wiki/Deng_Xiaoping) started changing China at the venerable age of 70+ moving forward until his death almost two decades later.
Do not underestimate wisdom as a cognitive skill, even if in today's world we tend to discredit it because of agism.
zelphirkalt 1 days ago [-]
To bring up politicians, in a discussion about mental peak performances ... yeah, no, it's funny.
DonHopkins 1 days ago [-]
It's as wrong to anthroporphize Emacs as it is Larry Ellison.
Steeeve 21 hours ago [-]
Back when I was on usenet, it was a common joke that all real programmers used emacs - and at the time I was a vi guy. It took me so long to get the muscle memory to do what I needed in vi that I thought I'd never change. But sure enough, I'm a nerd, and just like when I tried to learn the Dvorak keyboard layout, I decided to spend two weeks learning emacs. Absolutely frustrating for a few days. But I've been on emacs ever since. Some years I didn't update my emacs config or install any updates at all. Some years, that's MOST of what I did.
No shade at all to VIM or any other community of evangelists who have taken the time to get all the power they can out of their toolset. What works for you works.
But between org-mode and the 70 other features that I've come to know and love (like projectile, flycheck, ivy, m-x butterfly, yasnippet, etc.), I'm never looking back. I will occasionally use another tool for a specific purpose, and sometimes those tools have features and niceness that is hard to beat, but most of what I do professionally is just plain typing and I'm way more productive in emacs than any other typing tool.
Pretty cool that after all these years I can see an article like this and learn a thing or two as well. Thanks OP!
kqr 14 hours ago [-]
But you can get the best of both worlds by using Evil. That gets you Emacs-the-platform with Vim-the-editor.
glimshe 1 days ago [-]
Prediction: Emacs will reach super intelligence before Claude.
rgoulter 1 days ago [-]
I do wish that Emacs was more popular with LLM technologies.
LLMs are powerful at dealing with text. And Emacs is highly extensible and typically text-oriented. Already I see people say that LLMs much Emacs much easier to use (since you can ask an LLM to come up with the elisp for you), but I reckon what Emacs provides ought to be useful the other way.
With Emacs, it's common to see people favour bringing various parts of the system all within Emacs. I'm reminded of that when I've seen how useful it can be to provide API access to logging/code/documentation when asking an LLM to troubleshoot.
With LLMs, there are several uses cases I see which are a natural fit for org-mode, and just imitated in markdown. -- e.g. org mode have TODO items, checklists, tables (including spreadsheet functionality), code blocks, tagging/properties.
iLemming 1 days ago [-]
> I do wish that Emacs was more popular with LLM technologies.
Let's reword this a bit: "I wish Lisp use was more popular with LLMs...", because using Lisp REPL with AI is such a "life hack", I don't get why more people don't do that. When you give AI a "true Lisp REPL" it works wondrously - it stops randomly guessing and starts empirically understanding the problem and the code - saving time, tokens, your mental energy. And with Emacs' text manipulating machinery on top of that, things can get seriously interesting.
sinker 21 hours ago [-]
I've started experimenting with claude to run end-to-end tests for an emacs package I'm developing. It's incredible.
The way it works:
1. You start emacs in daemon (server) mode.
2. You prompt claude to instantiate an emacs client and write/run tests.
That's it.
Claude will then "pilot" an emacs instance where you can visibly see it running tests. Since almost everything is a first-class function in emacs, and emacs enables almost complete introspection, claude can debug the code in the execution environment. You can also just look at the piloted emacs instance and prompt the agent on what's wrong in the running application state.
This is much more thorough then just having claude write unit tests because many of the issues you might encounter are visual/gui things - which, again, because emacs allows so much introspection, can be examined by looking at the current application state.
This is a good example of "completing the loop."
mrhottakes 24 hours ago [-]
I thought this as well, so I spent a few days working with Claude in emacs. Claude managed to totally break my install by suggesting a bunch of "fixes" that were actually not fixes at all. Very poor performance, just hallucinating things left and right.
I don't need Anthropic to break my emacs, I can do that all by myself.
mplanchard 19 hours ago [-]
agent-shell is a great package. I’m not an AI booster by a long shot, but it makes integrating LLMs into your standard emacs flows ezpz
gpderetta 1 days ago [-]
No, I think that ̶w̶i̶n̶t̶e̶r̶m̶u̶t̶e̶ ̶w̶i̶l̶l̶ ̶m̶e̶r̶g̶e̶ ̶w̶i̶t̶h̶ ̶n̶e̶u̶r̶o̶m̶a̶n̶c̶e̶r̶ emacs will merge with claude instead.
(The prefix arg disables paperclips, for obvious reasons )
internet_points 1 days ago [-]
TIL about ruler-mode; now I can delete my own half-assed implementation of the same.
And compare-windows looks really handy. I was about to write a note in my init file to my future self telling me to start using that, but then I saw there is already a note there from my past self, telling me about compare-windows.
scroll-all-mode seems useful, but it seems to only handle keyboard scrolling, not mouse-wheel?
1 days ago [-]
internet_points 1 days ago [-]
...except ruler-mode uses dragging of middle mouse button to move the fill column, which on my system scrolls.
db48x 1 days ago [-]
Then simply change the keybindings.
Use `C-h k` and then middle click on the ruler-mode’s header to find out what command is bound to the middle mouse button, then bind that same command to a different mouse button:
Like you, I've been using emacs (gnu) for decades, and dired is my directory/file manipulation tool, for both linux and windows. I never see a desktop with files/folders or anything like that, it's dired for everything.
For example: Just a few minutes ago, in a directory with lots of PDFs, I did:
- wdired to rename pdfs to a consistent convention. Did this with the awesome multiple-cursors package, then interactively spell-checked and corrected my renamed pdfs. All within writeable dired :-)
- delete several non-pdf files
- mark several possible duplicate files and dired-do-shell-command with sha512sum
- move several pdfs to another directory
(split window and open target dir, mark files to move, one-button move using dired-dwim-target.
- mark several pdfs and open with reader app
Obviously that's all do-able with a shell or traditional file manager GUI, but dired was a total win here.
Multiply that win by a hundred times per week, and that's a quality of life enhancement.
kqr 14 hours ago [-]
> dired-dwim-target
Aha! That's what's been missing in my life! Thank you.
amszmidt 2 days ago [-]
Fun fact. DIRED pre-dates EMACS.
DIRED on ITS is also similar enough to today’s DIRED.
yxhuvud 1 days ago [-]
It has a million features I don't use. But some features are really, really nice, like C-q for editing file names (C-x-s to persist changes once done). Rectangle editing is so, so nice to have when renaming multiple files.
SoftTalker 1 days ago [-]
C-q just tells me the buffer is read-only. How does that work?
scoops_ 18 hours ago [-]
They probably mean ‘C-x C-Q’, which toggles a buffer with its read-only state. In this case it lets you edit the contents of the dired buffer (i.e directory or file names) to changing the buffer to wdired-mode, and then ‘C-x C-s’ to save the contents of the buffer, which changes the names and places the buffer back into read-only (dired-mode)
SoftTalker 2 hours ago [-]
Yes, that worked! Thanks. Though it was C-c C-c to save and exit the r/w mode.
rpdillon 1 days ago [-]
wdired is still magic to me. Use it almost every day.
unlogic 2 days ago [-]
Check out sunrise-commander, it is Dired reskinned as a dual-paner. Love how convenient it is to have a powerful integrated file manager.
kqr 1 days ago [-]
Is sunrise commander stable these days?
I tried using it maybe a decade ago and back then it had a tendency to mess up window layouts and leave weird buffers around. I notice there's now a GitHub repository which has two spurts of work in its history that probably didn't exist when I last used it – have they improved its usability?
m463 1 days ago [-]
I think 's' is sort.
More seriously, what I would like to do is ediff files (only the differences) in two directories (have the changed files together one line after the other)
or, ediff two arbitrary lists of files and have them show up in ediff.
agumonkey 21 hours ago [-]
it's bare but i'm surprised people would get confused by it, it kinda follows the usual shortcuts over bare unix util output: mark/select, delete, rename, compress, encrypt
then maybe you dislike the low-discoverability of shortcuts, i think someone added a transient layer (aka a visible shortcut summary with some state management for options)
rirze 2 days ago [-]
Try it out! It has its own learning curve, but it's convenient to use in quick and dirty situations.
wafflemaker 2 days ago [-]
Love that the "don't mess something up accidently" aka input lock is working in dired too(C-c C-q) Here it turns off input lock, so you can freely edit filenames in a dir like if it was a regular text buffer.
iLemming 15 hours ago [-]
I have an opposite argument - no other file manager ever worked for me and I tried and keep trying so many. And not because Dired "is so much better" or "far more capable", or "has better default keybindings", or due to my muscle memory or Stockholm syndrome, no. It's because I can always introspect every single feature of it, override any command, integrate things with any other packages.
I honestly think that we (programmers) collectively went backwards when we tried to abandon Lisp. Why aren't there [popular] apps with a built-in true Lisp REPL for file management, email, version control?
Misunderstanding (or complete incomprehension) of Lisp lead us to the mess we're in today. Some may say: "people made their choice", etc. Well, like so many times in history, majority is not always right, but quite the opposite. We spent almost 2000 years building with inferior Portland cement, which degrades in seawater within decades, instead of using techniques perfected by Romans. We keep piling the crap, making CO2 emissions even worse. And only because we lost the recipe. The Pantheon built with Roman harbor concrete that strengthens in seawater still stands. Emacs is the Pantheon of software - the monumental example of what we've lost, the shining display of continuous progress in a world of regression.
It is heartbreakingly sad because there's now an entire generation that has no clue, because they have not witnessed the decades of callback hell. They don't know anything (or wouldn't even want to know) about "Beating the Averages", Greenspun's Tenth Rule, Gabriel's "Worse Is Better" and how he was so conflicted about his own essay that he spent a decade writing rebuttals under a pseudonym.
Lisp won't ever die, but it will never regain its former supremacy. Because for humans, economic/social reasons matter more than technical merits.
fridder 1 days ago [-]
dirvish is nice
buzzwords 2 days ago [-]
I saw orgmode once and I really loved it. Used Doomed and spacemacs. But dear Lord, does everything break on updates and need fixing. I had to give up as I just don't think it's feasible for me to fix my emacs when I want to get some work done.
iLemming 1 days ago [-]
> does everything break on updates and need fixing
Emacs is a kitchen and emacs-packages are recipes - they come with the exact instructions (source code). If you try to cook fifty different meals all at once, your kitchen inevitably would be a mess. You need to know what you're trying to cook and how to work the recipes, and that comes with experience. No starter kit gives you a structure to un-mess your kitchen magically. Every sufficiently complex Emacs config is a system - a composite interweaving network of thousands of expressions, millions of code lines - it is the Space Shuttle equivalent; Neovim is like a simple twin-engine and VSCode is like a Cessna in comparison. Updates break your Emacs, I update things multiple times a week and rarely anything breaks (I consume over 350 packages); when things stop working - it doesn't usually take even a minute to figure out what's up. Yes, it does happen, but not as often as you painted it. On the other hand - when I need to get something done, there's no other tool in existence that can help me better.
mplanchard 19 hours ago [-]
TBF to the parent, I also started in spacemacs, then doom, before rolling my own config some years ago, and my early experiences also felt like upgrades were really hard to deal with and often breaking.
I think most of that was because I didn’t understand emacs itself very well, and doom or whatever is an entire extra layer of code and idioms on top of that. Start adding in any custom packages you’ve installed and things get well outside of the realm where a beginner can comprehend them.
Like you, I also now have a pretty large number of packages, and rarely run into issues on update, with any issues that do occur being easy enough to fix. However, I think a lot of that comes from at this point having built my own emacs from the ground up, so I understand what all the components are doing, mostly…
0xpgm 1 days ago [-]
I use vanilla emacs and compile from source straight from master at whatever commit it happens to be in when I decide to do it.
Only once was there a noticeable breakage when a command like `git log` in the terminal would spit out all its output instead of displaying one screenful at a time. I'd expect someone following stable releases wouldn't experience any breakages.
globular-toast 2 days ago [-]
What "updates" are you referring to? In more than 15 years of using Emacs I've not once been blocked from doing work due to any kind of breakage.
jjav 1 days ago [-]
Right, I can't understand what this breaking refers to?
I've been using emacs every day all day every time I'm front of a computer, since 1991. I need only one finger to count the pieces of software I've been using that long that have never crashed or broken on me in any way.
kqr 1 days ago [-]
I think it depends on which parts of the ecosystem you use. The org publication/export logic has changed a few times in the past 10 years. If you relied on quirks in that in your configuration you would have had to fix your code to repair it after some upgrades.[1]
I have also run into compatibility issues when using older versions of Emacs with newer packages, and newer Emacs versions with older packages.
[1]: I totally did not build my blog on top of a bunch of these quirks. Every time one of them is fixed I'm reminded of the workflow xkcd. https://m.xkcd.com/1172/
neutronicus 1 days ago [-]
I'm a Spacemacs user, and I just tried to update all my packages and my emacs is now somehow broken. Luckily I only did that one one of my two work machines so I will just do without the mac until I have the time to unfuck it.
jr_isidore 1 days ago [-]
He means time passing, aka bitrot. Emacs is designed for quick hacks which often rely on filesystem and shell behaviors outside itself to remain constant.
zelphirkalt 1 days ago [-]
I tried Doom or Spacemacs for a while, not sure which one right now. The one that does evil-mode by default. After it crashed a few times inexplicably, I gave up on them and returned to my heavily configured vanilla Emacs, which never crashes. Not sure how the other Emacsen managed to break things and maybe those failures are long fixed by now, but it was quite unfortunate. I imagine other people experiencing such a thing thinking Emacs is unstable.
binary132 2 days ago [-]
I’ve come to believe that this is less an emacs problem and more an “emacs plugins that try to do way too much stuff / take too much control” problem. I’m on vanilla emacs (I don’t even use use-package) and my config never breaks any more, even when upgrading major emacs versions. I think it’s about doing things in harmony with the emacs way instead of trying to take over the UI/UX. Emacs Live was always broken when I was using that.
zelphirkalt 1 days ago [-]
use-package is now in standard Emacs, so I would count that towards the Emacs way.
But I agree that it is very stable and for me also doesn't break, even though I use use-package a lot and install many key packages. Maybe it is important to note, that I don't need everything there is out there and that I remove not well working packages quickly after trying them. From time to time I also look at my init file and get rid of no longer used stuff.
quertyrecord74 1 days ago [-]
Also karthik is the author of gptel mode.
mintflow 2 days ago [-]
Nice write up about Emacs, ruler-mode is a thing I never used before.
Recently I finally start to C-X M-x to do text scaling, the typing is hard even as near 2 decades user of Emacs.
zelphirkalt 1 days ago [-]
Cool blog post. Though I think the blog post would benefit from having a table of contents. Some things one might know about or not be interested in, but one has to scroll through them anyway.
noelwelsh 1 days ago [-]
The biggest problem Emacs has will not be solved by blog posts like this. For most people the editor is a means to an end. They are invested in their end goal, not in hunting down blog posts telling them how to make better use of their tools. If Emacs wants wider adoption is needs a better out-of-the-box experience, which is something that distros like Doom Emacs and Spacemacs offer. That's the only way to make a dent: when people boot it up it has to have the good stuff right in their face. This also means ditching the "vanilla Emacs only" snobbery.
That said, I'm the kind of person to invest time in my editor and I appreciate this post.
michaelanckaert 1 days ago [-]
I understand your point of view, but as far as the Emacs community is concerned there is no problem.
Emacs is not an editor. Emacs is not an IDE.
Emacs is a platform to develop your own tooling. Text is the main interface Emacs offers.
I don't speak for the Emacs community, there isn't even such a thing except maybe semi related groups that share viewpoints, usage and interests. But on the whole, I don't think the "Emacs community" is looking for users or is looking to attract users. At least not users who are looking for "text editor experiences" that mimic or take inspiration from VS Code and the likes.
noufalibrahim 1 days ago [-]
I generally agree. I look at Emacs like a lisp interpreter with text editing primitives on which someone has built a decent editor.
There was a "community" about a decade or two ago. On Freenode IRC, there were regulars who hung around in #emacs and it was quite nice. There were no corporate sponsors or random startups trying to hire from there so it was genuinely just a bunch of people who enjoyed using Emacs and were chatting about it. It's a part of the reason I got really hooked into it. I still use Org heavily for meeting minutes etc.
michaelanckaert 1 days ago [-]
There is still a "community" on platforms such as Mastodon, reddit, various repo's. But I don't think there is a single community that can be pointed to as "The Emacs community". This would also be "wrong" from a Libre Software point of view.
lycopodiopsida 1 days ago [-]
There is no "problem" in emacs (there are big technical problems, but not this one) and no need to get "most people" on emacs - the ecosystem is healthy by all means and only increasing.
The "out of the box" experience could be better - but for emacs users. Those, who expect VS Code, should just install it and live happy.
pfortuny 1 days ago [-]
On your first paragraph: exactly. This is not a competition, Emacs is just shared software, not part of a market.
zelphirkalt 1 days ago [-]
I think whoever really wants to know what Emacs is about will give it a try and spend some time with it. Or some other distro like Doom Emacs or Spacemacs or stuff like that, if they are after a better out of the box experience.
What truly is a problem and extremely difficult to solve, is getting multi core and concurrency into Emacs properly. A truly concurrent lightweight thing would be so amazing to have and make package development probably much easier. No more worrying about accidentally blocking the UI and all that.
To get there would probably break many existing packages and would probably occupy all maintainers for 3 years or so, because Emacs comes from a time, where software was not designed to support that.
kqr 1 days ago [-]
That would be a problem if the Emacs project needed to attract new users that aren't "the kind of person to invest time in" their editor.
I'm not sure it does. Emacs has a healthy user base of people like you and I and appears to receive stable funding from the FSF. I don't see that changing any time soon. Emacs can be Emacs and be just fine the way it is.
I will keep suggesting new users should aim to get as close to vanilla as they have patience for, because that will teach them more about the powerful virtual machine running their text editor, and the ways it can be bent to do their bidding.
jr_isidore 1 days ago [-]
appears to receive stable funding from the FSF
No, about ten underemployed or semi-retired graybeards on the emacs.devel mailing list burn most of their waking hours futzing with emacs. That's not an exaggeration. They receive no remuneration.
kqr 1 days ago [-]
That's sad. Is there a way I can fund them without going through FSF? I tried looking into it before but it seemed like FSF was the only alternative, so I assumed it was well-managed.
Ah, thanks. At least one of them is apparently already receiving recurring donations from me!
jr_isidore 1 days ago [-]
Bro, the FSF is an unchecked post office box somewhere in Kendall Square, and besides, do you really think $10 per month makes a difference? I don't know what these guys feed off of, but it's not food or anything else that money buys.
beepbooptheory 1 days ago [-]
The emacs devel mailing list is way more active than that.. although you do see some regulars there for sure.
jr_isidore 1 days ago [-]
You misunderstand. Every mailing list has their healthy share of drive-by contributions, but emacs.devel contains a handful of dudes for whom *all they do* is emacs. We're talking nights, weekends, holidays. If they were indeed working a job, the inordinate time spent on the mailing list would constitute defrauding their employer.
kristjansson 1 days ago [-]
Why does emacs have to be for everyone? Its attraction, to this user at least, is the lifelong process of adaptation and discovery that molds it to the user, and the user to it.
It’s like a pet. I love my dog, I’m happy to tell you about my dog, share pictures, etc. But in sharing, I’m not asking you to take _my_ dog. If you’re inspired to go find your own dog, train it, care for it, you can have a dog too!
But neither taking my dog nor the first-day experience of your own dog will replicate, and asking for a dog with a good OOTB experience IMO misses the point.
neutronicus 1 days ago [-]
FWIW Spacemacs has been breaking on update for me with depressing regularity the past couple years. I'm afraid to do it
mplanchard 19 hours ago [-]
I have rolled my own config now, but I started in spacemacs, and then moved to doom a while later. FWIW I found doom much easier to grok and generally stabler.
steve-atx-7600 1 days ago [-]
aquaemacs was helpful for me when I was new to emacs backin ‘07. When I forgot some commands, having a gui with menus was handy.
rk06 1 days ago [-]
rest of the world is ctrl-c, ctrl-x and ctrl-v. but emacs is in completely different world.
for emacs to gain mindshare, it needs to meet people where they are, not where emacs was 30 yrs ago.
of course, emacs does not work reliably in windows, so that is another issue
amusingimpala75 1 days ago [-]
M-x cua-mode enables a variety of “traditional” keybinds such as C-x / C-c / C-v for cut / copy / paste
kristjansson 1 days ago [-]
Learning that those shortcuts are arbitrary, application-defined conventions is the first step toward enlightenment.
Matumio 1 days ago [-]
> of course, emacs does not work reliably in windows, so that is another issue
No, it's the same issue. In a Linux shell (say, bash or fish) ctrl-c is not "copy" but "terminate program". Most emacs editing keys (copy-paste, motion) work in the shell as they do in emacs, at least in fish and bash (and probably other places in Linux).
simiones 1 days ago [-]
Ctrl-C in Emacs is not "terminate program", it is "start of user command", in most modes. Similarly, even in vi/vim, Ctrl-C does something completely different. So this has nothing to do with the terminal whatsoever.
saltcured 1 days ago [-]
It's an even more basic Unix affordance, that terminals had a key-binding that generated the interrupt signal, and programs could define useful behaviors that commenced upon receipt of interrupt.
It made sense that interrupt in Emacs could get into a controlled state of receiving the next command. It's a little bit like the SAK (secure attention key) concept, as seen with Windows use of ctrl-alt-del.
Edit: Ironically, as a long-term emacs user, I don't really remember any commands that start with ctrl-c! For me, the most common sequences start with ctrl-X or meta-X. Or the prefix search commands ctrl-S and ctrl-R.
simiones 4 hours ago [-]
If you are running Emacs, either in the terminal or in graphical mode, pressing Ctrl+C does not generate any interrupt signal, it simply passes the C-c key to Emacs, which is just a general key bind.
Now, C-c in particular is the key stroke which non-core modes are recommended to use for their key binds (for example, sgml-mode uses C-c as a prefix for all of its commands, e.g. C-c C-f for sgml-skip-tag-forward, C-c C-b for sgml-skip-tag-backward, etc). Running `killall -SIGINT emacs` will not be interpreted as a C-c key being hit in emacs, it will just cause emacs to quit.
The same thing is true for other terminal based programs, like vi. Pressing Ctrl+C in vi does not generate an interrupt signal, it just passes this key combo to vi to do with as it pleases.
skydhash 1 days ago [-]
Ctrl-c is mostly for modes, not core emacs. Org-mode and gnus have a lot of bindings. But there’s a convention that ctrl-c then <character> are not to be bound. There needs to be a modifier for <character>
jr_isidore 1 days ago [-]
Half of the obscure features mentioned required the author's massaging to make useful to himself. The history of these "solutions looking for a problem" is common, some guy reveling in a rabbit hole of his own creation, the only difference being that guy was old enough to have a gnu.org email address whereas the rest of us publish our dabblings on github as third-party packages.
This reminds me of the fading but ever present power of institutionalism. For probably good reasons we accord higher respect to the Tonight Show than some rando podcaster. But at least in emacs's case, there really is no quality difference between a "batteries included" mode and one off the rack.
justinhj 1 days ago [-]
Both Emacs and Neovim reward rtfm and working up from a vanilla configuration to your own custom one.
The distribution style packages for these editors make the user skip all that initial learning and discovery. It leads to people writing plugins and packages that simply replicate what was already possible. I have written plenty of elisp myself only to find out I was rewriting builtin functionality.
I'd also say that both editors are fully discoverable but you have to first learn how to use the various help available. Emacs is a bit ahead here with its help options, letting you search for functions, variables, info and man pages, apropos (fuzzy search) and more.
In short start vanilla and explore; this kind of blog really helps with that.
gnulinux 2 days ago [-]
My 2 cents (I hope I don't offend anyone, and of course Emacs community is amazing). I've been using Emacs full-time since ~2010 but I must admit it's been more like part-time along with VSCode since ~2024.
> This is largely a discoverability problem
In my experience it's not a discoverability problem at all. Not even a little bit. My problem with emacs batteries has always been stability between different combinations of packages. I know how to use dired, I know how to install elisp packages, I know how to write emacs lisp myself. The issue with emacs is that it's difficult to create large packages with "batteries" because any additional package added can bork some random, seemingly unrelated package. E.g. back in the day (maybe around ~2020s or a bit before?) I've been using Spacemacs without vim keybinding, and although batteries were included and I was happy, this issue I mentioned above was even bigger. Because I constantly had to deal with installing a package and discovering that it broke some unrelated LSP, programming, or autocomplete package. It gets quite a bit frustrating at some point. Since this LLM madness started, I never really installed anything LLM related to Emacs, and have been using other text editor for LLM related stuff, Emacs for everything else (especially if there is a strong Emacs package, e.g. agda2-mode is incredibly good, almost flawless!)
Again, just my humble two cents. Obvious Emacs is amazing, and in many ways it's still my go-to, I just think that the biggest issue for me has always been randomly broken packages. Maybe I'm a terrible elisp programmer, that's possible! But I've been using emacs everyday for decades, so idk...
zelphirkalt 1 days ago [-]
My guess is, that writing Emacs packages requires a lot of discipline, to only use the minimal surface one needs from Emacs. And that is, because of the huge amount of mutable global state in Emacs. An actual design flaw, that is sometimes super useful, but at other times super annoying.
gpderetta 1 days ago [-]
I'm often amazed how things do not break more often than they do[1] given how deep a package can alter emacs intenrals.
[1] and they do break!
Paradigma11 1 days ago [-]
LLMs are a godsend in fixing emacs problems.
tapete1 1 days ago [-]
I have asked LLMs several Emacs-related questions and _never_ got a reply that works. And at generating elisp code they are especially awful.
SoftTalker 1 days ago [-]
Same. I'm not an elisp expert by any means, so I tried using claude and chatgpt to help me write some functions. They got close, close enough that I could massage what they wrote into something that did what I needed, but they have never produced anything that just worked.
antiframe 1 days ago [-]
That is not my experience. I had Claude add a variety of useful functions to my init.el as well as refactor it for easier maintenance. I now have a more useful to use and pleasant to edit init for it.
neutronicus 1 days ago [-]
Yeah, Claude has helped me fix a bunch of warts I was just living with.
mrhottakes 23 hours ago [-]
Agreed, Claude didn't seem capable of doing anything but hallucinating "fixes" and breaking my config.
jr_isidore 1 days ago [-]
Try asking it a coding question, one that doesn't diminish your self-worth.
cmrdporcupine 24 hours ago [-]
Not my experience. I've had them write modes for new languages from scratch with excellent results.
And diagnose and fix up my emacs configuration.
Even back in pre-Opus 4.5 days I found them incredibly useful for elisp diagnostics, and these days I use Codex to great effect to enhance my emacs setup.
zelphirkalt 1 days ago [-]
Question: Why VSCode spyware? Why not at least VSCodium? Or is this just a case like people saying Chrome, when they have Chromium or Ungoogled-Chromium?
skydhash 2 days ago [-]
Both you and the sibling common by buzzwords have the same contexte: You’re both using someone’s configuration framework, which goes bery much against the vanilla emacs’s way. Most package assumes something standard and you can expect something to break if your configuration isn’t.
noelwelsh 1 days ago [-]
I've used Doom Emacs for years and it rarely breaks. Sometimes things get out of sync, and I delete the git repo and clone it again. That happens once every few years.
People holding your attitude is one thing that keeps people away from Emacs. Very few people want to get into the weeds of customizing their editor. They want to do whatever it is they are interested in and the editor is tool to get it done. Doom Emacs, and other approachable "distributions" are the way to make the power of Emacs accessible.
shevy-java 2 days ago [-]
> You’re both using someone’s configuration framework, which goes bery much against the vanilla emacs’s way
I heard a similar argument about vim's billion configuration options.
At some point I simply got tired of having to tweak it and switched to a better editor (not emacs though; both vim and emacs are losing in any debate, but it's a fun debate nonetheless since both camps think software can only be written with these two editors; everyone else must be clueless and skillless).
antiframe 1 days ago [-]
You met some odd Emacs users. Every Emacs user I have met is a strong proponent of personal computing and crafting tools that work for the individual. It's true that some have a hatred of software that removes users' freedoms but that doesn't mean they think users of freedom-restricting software are skilless.
garn810 2 days ago [-]
Spacemacs is kind of bloated and easy to break with custom packages which are not part of original build
shevy-java 2 days ago [-]
Emacs is a great OS. If you complement it with vim then you may have a working editor as well, provided you know how to exit from vim.
neutronicus 1 days ago [-]
Just use the emacs-native implementation (evil-mode).
__patchbit__ 2 days ago [-]
Emacs is the AI acupuncture livecode needle probe into AI robotics. Pair it with Helix editor for the old and true, refresh new experience.
DonHopkins 2 days ago [-]
I LOVE Emacs, but I HATE it when I have the irresistible urge to edit text, but Emacs has dead batteries.
I used to be on neovim, and that ecosystem compared to emacs feels like this image: https://i.imgflip.com/2pg2s7.jpg
Some of it is the maintainer shielding us from the breaking changes, but I also think the ecosystem is more slow moving than other editors which helps. The editor is older than most devs after all.
You're probably thinking of kill ring, which I always thought was a neat term.
Nothing's wrong with it. It's just incomparable categorically. Just like you can't really equate a photo-editor and the web-browser. Sure, there's a way to do photo editing in the browser, still will be weird to compare them.
> Neovim has been much better
In what sense? Emacs is a Lisp interpreter with a text editor embedded in it - one can fully emulate Neovim features in it, the opposite is hardly possible - you can bolt Lisp interpreter on top of Neovim, but it won't be the same.
> I just want a good text editor
Is that implying Emacs doesn't have "a good one"? You probably just have not discovered some mind-blowing features of the editor. It is hands down the best-known machine ever designed to deal with plain text, nothing even comes close. Indirect buffers alone are such a brilliant idea, I have zero clue how people ever exposed to that power would willingly abandon it. I get it though, building a text-manipulating theater orchestrated by Lisp is not for everyone. Unfortunately, most newcomers get attracted to Emacs hearing "how powerful an editor it is", without ever learning what exactly makes it as such.
The big reason I switched is because a lot of the big features of Emacs (org mode, magit, "living" in Emacs, advanced text manipulation, the extreme extensibility of the software) were things that sound really amazing on paper, but in practice I just don't really need/use/care about, and that's just my preferences. But once again, Emacs is cool and I totally respect what it can do.
It's almost invariably about the trade-offs, without knowing what they are and how to navigate them would remain a highly debatable topic.
You have fixated on a single (albeit voluminous) aspect of things to make a choice. But there are dozens of other things we can drop there and steer away from Emacs with wrong conclusions, e.g. Emacs has mail client capabilities, and for anyone unfamiliar with Lisp, it might be obvious - more specialized email apps would look far more capable. But for an experienced Lisper, no specialized app would ever suffice. Particularly because Lisp allows them to adapt things with extreme precision, specifically for their use cases.
> The big reason I switched
You have switched (as it seems) without even understanding what it was about. It's not about Org, Magit, or any other "features" of Emacs. The main idea is and always was the Lisp interpreter. For someone like me (staunch Lisper) Magit is not some "packaged", ready-to-use piece of software, it's a set of libraries I can use. I can easily incorporate just about any Magit function into my workflow directly. I don't have to submit patches, I don't have to ask anyone's permission, I don't have to guess - the source code is given, I don't even have to save my experiments anywhere - I can just start typing Elisp code in my scratch buffer and eval things in place. Similarly - I use Org-mode for a bunch of things that may sound absolutely unrelated - I consume HN, Reddit, Jira, GitHub, Slack and other content in org-mode derived buffers. Why? Again, because of bunch of APIs, functions and commands that Org provides. I can for example easily retrieve any HN thread and extract all the URLs people posted in comments, and inspect each in-place - takes me a keystroke. Or I can send the text to an LLM - without ever copying and pasting, without context switching, without losing focus. No other [popular] piece of software ever granted me such enormous power and liberation.
I am absolutely so grateful to my younger self for forcing me to grok Emacs and Lisp, and I will never understand the sentiment and the "reasoning" of people moving away from it (after being exposed to its absolute supremacy over plain text). Realistically, there's never switching away from Emacs for me, that, unless a better Lisp engine emerges at some point. And btw. I am a die-hard Vimmer. I use vim motions everywhere - system wide. They permeate my editors/IDEs, web browsers, terminals, and yes, even Emacs. And I use Neovim as well - it works well when I need to reach for it - like I said: it's not a comparison.
Unless this is specifically what you want to do with Neovim, in which case you'll probably just use Emacs anyway, Neovim's inability to do this is probably not a strike against it. As royal__ says (https://news.ycombinator.com/item?id=48537120), they are just interested in a good text editor, not in raw computational power.
A common reason for breakage is/was:
But: The latest example of #1 is vim.pack, which is a plugin manager similar to vim-plug, mini.deps (vim.pack is based on mini.deps), lazy et cetera.I can remember removing vim-commentary (from tpope) a while ago because Neovim included something like it in the main distribution. Granted, that specific plugin never broke because it uses the stable viml API.
No such thing exist in neovim (or at least in times when I was using it), so that churn never ends. Also I find, that neovim ecosystem is concentrated on one (very productive) developer in an unhealthy manner - folke often takes time off and half the packages one uses stands still.
But in the end, while I like neovim, I also find that emacs ecosystem has better ideas - which-key, embark do not stop to amuse me (I will not comment on whether it is a good thing for a text editor). I also do not like lua and actively dislike the experience of debugging and configuring neovim with it (maybe less of an issue with LLM these days).
In my experience, running in a terminal absolutely adds a bunch of rendering/performance issues and all kind of surprising failures with hotkeys.
> No such thing exist in neovim
neovim has been doing that too. Plugin manager (vim.pack), treesitter stuff, LSP management, completion, comments, etc.
> which-key
neovim also has this.
> neovim ecosystem is concentrated on one (very productive) developer in an unhealthy manner
folke has nice stuff, but I find a lot of it is largely unnecessary and bloated. The only thing I use is his which-key, and there are alternatives, such as mini.clue.
I used it more than I use emacs, but I agree with the assessment of doom emacs vs neovim.
I hope with these new built in alternatives that will change.
It’s a bit sad Neovim has stolen the thunder from the original work of Moolenaar & co. My guess is that neovim will splinter itself down the line further again once lua stops being attractive, while vim & Emacs will keep chugging along for another half century.
It's like a willful exercise in ignoring systems thinking. With Emacs every package tends to be designed with Emacs itself in mind, packages like consult, vertico, marginalia etc all built on Emacs' facilities improving not just the package itself but the overall experience of using Emacs, intentionally so.
The Neovim ecosystem is a bit like a dozen architects each designing a room in a house with total disregard for the layout of the house. A very common experience I had, and I never even used many plugins, was that when something was updated often something else would break. An update in the completion engine would cause some weird quirk with the lsp backend, etc.
Neovim seems fairly reasonable. Using the LazyVim distribution of Neovim and it works quite well for my purposes.
Respect where it's due to folke, he's been pushing the neovim ecosystem forward incredibly fast. The bleeding edge just ain't everyone's style though.
Seems worth a look, simply because it’s from the magit author.
> The editor is older than most devs after all.
Well, being old does not automatically mean better. Peak human physical performance typically happens, with some exceptions (Justin Gatlin, if we ignore the use of enhancement drugs) in younger years; see Usain Bolt's fastest time achieved when he was young (23 years, in 2009). For mental tasks it is not so limited, but for physical peaks it is often in the younger years. For some software projects it also is the case that older age means more code, which in turn automatically mean smore bugs, all other things being equal. I am not necessarily questioning as to whether emacs has more bugs; my point is that the comparison/analogy does not work as means of quality assessment.
You just cannot compare software robustness to human lifespan. Does software need 3 years at the bare minimum to be self-sufficient? Does it become argumentative and crashes a lot after 13-14 years?
Do not underestimate wisdom as a cognitive skill, even if in today's world we tend to discredit it because of agism.
No shade at all to VIM or any other community of evangelists who have taken the time to get all the power they can out of their toolset. What works for you works.
But between org-mode and the 70 other features that I've come to know and love (like projectile, flycheck, ivy, m-x butterfly, yasnippet, etc.), I'm never looking back. I will occasionally use another tool for a specific purpose, and sometimes those tools have features and niceness that is hard to beat, but most of what I do professionally is just plain typing and I'm way more productive in emacs than any other typing tool.
Pretty cool that after all these years I can see an article like this and learn a thing or two as well. Thanks OP!
LLMs are powerful at dealing with text. And Emacs is highly extensible and typically text-oriented. Already I see people say that LLMs much Emacs much easier to use (since you can ask an LLM to come up with the elisp for you), but I reckon what Emacs provides ought to be useful the other way.
With Emacs, it's common to see people favour bringing various parts of the system all within Emacs. I'm reminded of that when I've seen how useful it can be to provide API access to logging/code/documentation when asking an LLM to troubleshoot.
With LLMs, there are several uses cases I see which are a natural fit for org-mode, and just imitated in markdown. -- e.g. org mode have TODO items, checklists, tables (including spreadsheet functionality), code blocks, tagging/properties.
Let's reword this a bit: "I wish Lisp use was more popular with LLMs...", because using Lisp REPL with AI is such a "life hack", I don't get why more people don't do that. When you give AI a "true Lisp REPL" it works wondrously - it stops randomly guessing and starts empirically understanding the problem and the code - saving time, tokens, your mental energy. And with Emacs' text manipulating machinery on top of that, things can get seriously interesting.
The way it works:
1. You start emacs in daemon (server) mode.
2. You prompt claude to instantiate an emacs client and write/run tests.
That's it.
Claude will then "pilot" an emacs instance where you can visibly see it running tests. Since almost everything is a first-class function in emacs, and emacs enables almost complete introspection, claude can debug the code in the execution environment. You can also just look at the piloted emacs instance and prompt the agent on what's wrong in the running application state.
This is much more thorough then just having claude write unit tests because many of the issues you might encounter are visual/gui things - which, again, because emacs allows so much introspection, can be examined by looking at the current application state.
This is a good example of "completing the loop."
I don't need Anthropic to break my emacs, I can do that all by myself.
And compare-windows looks really handy. I was about to write a note in my init file to my future self telling me to start using that, but then I saw there is already a note there from my past self, telling me about compare-windows.
scroll-all-mode seems useful, but it seems to only handle keyboard scrolling, not mouse-wheel?
Use `C-h k` and then middle click on the ruler-mode’s header to find out what command is bound to the middle mouse button, then bind that same command to a different mouse button:
For example: Just a few minutes ago, in a directory with lots of PDFs, I did:
- wdired to rename pdfs to a consistent convention. Did this with the awesome multiple-cursors package, then interactively spell-checked and corrected my renamed pdfs. All within writeable dired :-)
- delete several non-pdf files
- mark several possible duplicate files and dired-do-shell-command with sha512sum
- move several pdfs to another directory (split window and open target dir, mark files to move, one-button move using dired-dwim-target.
- mark several pdfs and open with reader app
Obviously that's all do-able with a shell or traditional file manager GUI, but dired was a total win here.
Multiply that win by a hundred times per week, and that's a quality of life enhancement.
Aha! That's what's been missing in my life! Thank you.
DIRED on ITS is also similar enough to today’s DIRED.
I tried using it maybe a decade ago and back then it had a tendency to mess up window layouts and leave weird buffers around. I notice there's now a GitHub repository which has two spurts of work in its history that probably didn't exist when I last used it – have they improved its usability?
More seriously, what I would like to do is ediff files (only the differences) in two directories (have the changed files together one line after the other)
or, ediff two arbitrary lists of files and have them show up in ediff.
then maybe you dislike the low-discoverability of shortcuts, i think someone added a transient layer (aka a visible shortcut summary with some state management for options)
I honestly think that we (programmers) collectively went backwards when we tried to abandon Lisp. Why aren't there [popular] apps with a built-in true Lisp REPL for file management, email, version control?
Misunderstanding (or complete incomprehension) of Lisp lead us to the mess we're in today. Some may say: "people made their choice", etc. Well, like so many times in history, majority is not always right, but quite the opposite. We spent almost 2000 years building with inferior Portland cement, which degrades in seawater within decades, instead of using techniques perfected by Romans. We keep piling the crap, making CO2 emissions even worse. And only because we lost the recipe. The Pantheon built with Roman harbor concrete that strengthens in seawater still stands. Emacs is the Pantheon of software - the monumental example of what we've lost, the shining display of continuous progress in a world of regression.
It is heartbreakingly sad because there's now an entire generation that has no clue, because they have not witnessed the decades of callback hell. They don't know anything (or wouldn't even want to know) about "Beating the Averages", Greenspun's Tenth Rule, Gabriel's "Worse Is Better" and how he was so conflicted about his own essay that he spent a decade writing rebuttals under a pseudonym.
Lisp won't ever die, but it will never regain its former supremacy. Because for humans, economic/social reasons matter more than technical merits.
Emacs is a kitchen and emacs-packages are recipes - they come with the exact instructions (source code). If you try to cook fifty different meals all at once, your kitchen inevitably would be a mess. You need to know what you're trying to cook and how to work the recipes, and that comes with experience. No starter kit gives you a structure to un-mess your kitchen magically. Every sufficiently complex Emacs config is a system - a composite interweaving network of thousands of expressions, millions of code lines - it is the Space Shuttle equivalent; Neovim is like a simple twin-engine and VSCode is like a Cessna in comparison. Updates break your Emacs, I update things multiple times a week and rarely anything breaks (I consume over 350 packages); when things stop working - it doesn't usually take even a minute to figure out what's up. Yes, it does happen, but not as often as you painted it. On the other hand - when I need to get something done, there's no other tool in existence that can help me better.
I think most of that was because I didn’t understand emacs itself very well, and doom or whatever is an entire extra layer of code and idioms on top of that. Start adding in any custom packages you’ve installed and things get well outside of the realm where a beginner can comprehend them.
Like you, I also now have a pretty large number of packages, and rarely run into issues on update, with any issues that do occur being easy enough to fix. However, I think a lot of that comes from at this point having built my own emacs from the ground up, so I understand what all the components are doing, mostly…
Only once was there a noticeable breakage when a command like `git log` in the terminal would spit out all its output instead of displaying one screenful at a time. I'd expect someone following stable releases wouldn't experience any breakages.
I've been using emacs every day all day every time I'm front of a computer, since 1991. I need only one finger to count the pieces of software I've been using that long that have never crashed or broken on me in any way.
I have also run into compatibility issues when using older versions of Emacs with newer packages, and newer Emacs versions with older packages.
[1]: I totally did not build my blog on top of a bunch of these quirks. Every time one of them is fixed I'm reminded of the workflow xkcd. https://m.xkcd.com/1172/
But I agree that it is very stable and for me also doesn't break, even though I use use-package a lot and install many key packages. Maybe it is important to note, that I don't need everything there is out there and that I remove not well working packages quickly after trying them. From time to time I also look at my init file and get rid of no longer used stuff.
Recently I finally start to C-X M-x to do text scaling, the typing is hard even as near 2 decades user of Emacs.
That said, I'm the kind of person to invest time in my editor and I appreciate this post.
Emacs is not an editor. Emacs is not an IDE. Emacs is a platform to develop your own tooling. Text is the main interface Emacs offers.
I don't speak for the Emacs community, there isn't even such a thing except maybe semi related groups that share viewpoints, usage and interests. But on the whole, I don't think the "Emacs community" is looking for users or is looking to attract users. At least not users who are looking for "text editor experiences" that mimic or take inspiration from VS Code and the likes.
There was a "community" about a decade or two ago. On Freenode IRC, there were regulars who hung around in #emacs and it was quite nice. There were no corporate sponsors or random startups trying to hire from there so it was genuinely just a bunch of people who enjoyed using Emacs and were chatting about it. It's a part of the reason I got really hooked into it. I still use Org heavily for meeting minutes etc.
The "out of the box" experience could be better - but for emacs users. Those, who expect VS Code, should just install it and live happy.
What truly is a problem and extremely difficult to solve, is getting multi core and concurrency into Emacs properly. A truly concurrent lightweight thing would be so amazing to have and make package development probably much easier. No more worrying about accidentally blocking the UI and all that.
To get there would probably break many existing packages and would probably occupy all maintainers for 3 years or so, because Emacs comes from a time, where software was not designed to support that.
I'm not sure it does. Emacs has a healthy user base of people like you and I and appears to receive stable funding from the FSF. I don't see that changing any time soon. Emacs can be Emacs and be just fine the way it is.
I will keep suggesting new users should aim to get as close to vanilla as they have patience for, because that will teach them more about the powerful virtual machine running their text editor, and the ways it can be bent to do their bidding.
No, about ten underemployed or semi-retired graybeards on the emacs.devel mailing list burn most of their waking hours futzing with emacs. That's not an exaggeration. They receive no remuneration.
It’s like a pet. I love my dog, I’m happy to tell you about my dog, share pictures, etc. But in sharing, I’m not asking you to take _my_ dog. If you’re inspired to go find your own dog, train it, care for it, you can have a dog too!
But neither taking my dog nor the first-day experience of your own dog will replicate, and asking for a dog with a good OOTB experience IMO misses the point.
for emacs to gain mindshare, it needs to meet people where they are, not where emacs was 30 yrs ago.
of course, emacs does not work reliably in windows, so that is another issue
No, it's the same issue. In a Linux shell (say, bash or fish) ctrl-c is not "copy" but "terminate program". Most emacs editing keys (copy-paste, motion) work in the shell as they do in emacs, at least in fish and bash (and probably other places in Linux).
It made sense that interrupt in Emacs could get into a controlled state of receiving the next command. It's a little bit like the SAK (secure attention key) concept, as seen with Windows use of ctrl-alt-del.
Edit: Ironically, as a long-term emacs user, I don't really remember any commands that start with ctrl-c! For me, the most common sequences start with ctrl-X or meta-X. Or the prefix search commands ctrl-S and ctrl-R.
Now, C-c in particular is the key stroke which non-core modes are recommended to use for their key binds (for example, sgml-mode uses C-c as a prefix for all of its commands, e.g. C-c C-f for sgml-skip-tag-forward, C-c C-b for sgml-skip-tag-backward, etc). Running `killall -SIGINT emacs` will not be interpreted as a C-c key being hit in emacs, it will just cause emacs to quit.
The same thing is true for other terminal based programs, like vi. Pressing Ctrl+C in vi does not generate an interrupt signal, it just passes this key combo to vi to do with as it pleases.
This reminds me of the fading but ever present power of institutionalism. For probably good reasons we accord higher respect to the Tonight Show than some rando podcaster. But at least in emacs's case, there really is no quality difference between a "batteries included" mode and one off the rack.
The distribution style packages for these editors make the user skip all that initial learning and discovery. It leads to people writing plugins and packages that simply replicate what was already possible. I have written plenty of elisp myself only to find out I was rewriting builtin functionality.
I'd also say that both editors are fully discoverable but you have to first learn how to use the various help available. Emacs is a bit ahead here with its help options, letting you search for functions, variables, info and man pages, apropos (fuzzy search) and more.
In short start vanilla and explore; this kind of blog really helps with that.
> This is largely a discoverability problem
In my experience it's not a discoverability problem at all. Not even a little bit. My problem with emacs batteries has always been stability between different combinations of packages. I know how to use dired, I know how to install elisp packages, I know how to write emacs lisp myself. The issue with emacs is that it's difficult to create large packages with "batteries" because any additional package added can bork some random, seemingly unrelated package. E.g. back in the day (maybe around ~2020s or a bit before?) I've been using Spacemacs without vim keybinding, and although batteries were included and I was happy, this issue I mentioned above was even bigger. Because I constantly had to deal with installing a package and discovering that it broke some unrelated LSP, programming, or autocomplete package. It gets quite a bit frustrating at some point. Since this LLM madness started, I never really installed anything LLM related to Emacs, and have been using other text editor for LLM related stuff, Emacs for everything else (especially if there is a strong Emacs package, e.g. agda2-mode is incredibly good, almost flawless!)
Again, just my humble two cents. Obvious Emacs is amazing, and in many ways it's still my go-to, I just think that the biggest issue for me has always been randomly broken packages. Maybe I'm a terrible elisp programmer, that's possible! But I've been using emacs everyday for decades, so idk...
[1] and they do break!
And diagnose and fix up my emacs configuration.
Even back in pre-Opus 4.5 days I found them incredibly useful for elisp diagnostics, and these days I use Codex to great effect to enhance my emacs setup.
People holding your attitude is one thing that keeps people away from Emacs. Very few people want to get into the weeds of customizing their editor. They want to do whatever it is they are interested in and the editor is tool to get it done. Doom Emacs, and other approachable "distributions" are the way to make the power of Emacs accessible.
I heard a similar argument about vim's billion configuration options.
At some point I simply got tired of having to tweak it and switched to a better editor (not emacs though; both vim and emacs are losing in any debate, but it's a fun debate nonetheless since both camps think software can only be written with these two editors; everyone else must be clueless and skillless).
https://www.youtube.com/watch?v=D1sXuHnf_lo