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?
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.
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.
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.
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)
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.
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.
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.
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.
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?
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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/
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.
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.
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...
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.
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?
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.
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.
> 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).
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?
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.
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.
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.
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.
That's right teco/emacs pre-dates xerox gypsy, which coined cut/copy/paste.
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)
I think Neovim itself has been stabilizing quite a bit in terms of upgrade breakage.
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.
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.
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.
To be fair, there are also tons of ways to manage packages in Emacs.
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.
That’s a serious misreading of the NeoVim ecosystem, and I’d bet good money against your predictions coming true.
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.
Use borg package. You'll get rock solid emacs. Worth the effort.
Link: https://github.com/emacscollective/borg
Seems worth a look, simply because it’s from the magit author.
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.
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?
If you look at the output of mathematicians and their biggest discoveries it suggests that it is similarly limited for mental tasks.
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.
To bring up politicians, in a discussion about mental peak performances ... yeah, no, it's funny.
It's as wrong to anthroporphize Emacs as it is Larry Ellison.
I have been using Emacs since 1994 (Lucid!) and I still don't understand Dired.
NGL, I find the Dired UX out of the box to be frustrating given its reliance on remembering key bindings, so much so that I ended up writing both a Transient menu and a context menu for it, both available in the Casual and Anju packages on MELPA, respectively. If interested, you can read more about them in the following links: https://kickingvegas.github.io/casual/Dired-Usage.html https://kickingvegas.github.io/anju/Dired-Mode-Context-Menu....
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.
Fun fact. DIRED pre-dates EMACS.
DIRED on ITS is also similar enough to today’s DIRED.
Check out sunrise-commander, it is Dired reskinned as a dual-paner. Love how convenient it is to have a powerful integrated file manager.
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?
Try it out! It has its own learning curve, but it's convenient to use in quick and dirty situations.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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/
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.
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.
Also karthik is the author of gptel mode.
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.
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...
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.
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?
LLMs are a godsend in fixing emacs problems.
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.
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.
> 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).
Spacemacs is kind of bloated and easy to break with custom packages which are not part of original build
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.
Emacs is the AI acupuncture livecode needle probe into AI robotics. Pair it with Helix editor for the old and true, refresh new experience.
I LOVE Emacs, but I HATE it when I have the irresistible urge to edit text, but Emacs has dead batteries.
https://www.youtube.com/watch?v=D1sXuHnf_lo