The model of computer use that appeals to me are the one that in theory have a simple system, but the real goal is for you to have a tool that fits your needs. So far it includes the BSDs (Unix), Emacs, and Smalltalk. I've not tried Plan 9 yet.
The more I'm learning more about the above, the more I'm believing that most computer problems has been solved since a long time and the focus should be on improving and creating new tools, not reinventing them.
PS: Spreadsheets are nice too, but they're still lacking the surrounding helpers that would make them great. There's VBA in excel, but I'm thinking about more like dynamic table that's linked to an endpoint or some commands (Unix's ps). I haven't explored tools like Airbase to see if they fit that vision.
Yes! Recent personal hacks with advice interactively programmed with the help of Claude 4.1 chat session running in Emacs.
- popping the global mark to travel backwards to previous edit points would reuse the same Emacs window instead of using a window that is already showing the buffer. Fixed
- I would accidentally destroy my window configuration w/ C-x 1. Fixed, use advice to automatically save the window configuration into a register if I invoke the command to remove all other windows. Now I can easily recover if I make that mistake.
- I want to be able to select and then scroll any other open window w/o leaving the current one. Fixed
- A crazy one. I collect note w/ links or whatever for reading/watching later, these are marked w/ a timestamp. My notes file is not an agenda file, i.e. not filled with todos / tasks. I made a hack to temporarily include the current non-agenda org-mode buffer in the agenda list and then show inactive timestamps. Now I can scan a day/week/month for interesting notes I took. This doesn't interact at all with my real agenda.
- org-agenda opens items in weird places, use advice to fix it so that it always appears where I like.
- fix inf-clojure so that it uses dep.edn as project root over .git
I used IntelliJ happily for 10 years (I was a heavy Emacs user for 10 years before that). While it's true that some things are a little less convenient (I don't use LSP), knowing that I can tailor things exactly to my tastes is a serious breath of fresh air.
It used to be I mostly used IntelliJ for work/OSS and Emacs for org-mode. Now the situation is likely reversed. Emacs for work/OSS and IntelliJ only if I need step debugging/global refactoring.
Having used emacs for many years, OP's description of "doing things wrong" is exactly the way I use emacs.
I seldom care about the inner workings of emacs and will do the absolute minimum to get it to work the way I want and then move on. I'm reminded over and over again that Emacs patinas really nicely with poorly written elisp in an init file over time.
Case in point, I found that org-export is super slow. After profiling it, I found the slow function, copied it, removed the slow part, and advice-add it right back in there[0]. Might this break some other deeply intertwined behavior someplace else? Probably. Does it matter if I'm the only one using it? Nope.
This isn't about adapting to future changes, but noticing breakage in the current system.
But also, even in FOSS there can be projects that value stability and isolation, so if you fix some plugin that misbehaves you don't need to adapt because the underlying editor APIs that plugin relied on are stable and also isolated in a way where your changes can't break other users
Learning and using Emacs is possibly the activity with the highest ROI over time you can do if you work with text for a living. Maybe even if you don't.
Every time you modify it, you are improving your workflow. Those changes compound over time so that the system is always familiar, which makes interacting with text, the filesystem, network, and anything else you can manipulate with Elisp, that much easier, faster, and more comfortable. What you end up with is a system that is unique to you. A system that does what you want the way you want it, and never changes unless you want it to. In a world where software constantly changes and breaks, where new editors appear and disappear, using your own version of Emacs is incredibly comforting. There are no surprises, no rugpulls, no radical UI redesigns, no sneaky telemetry or tracking, no ads, no nagware, and so on. Anything you don't like can be removed, changed, or improved.
It's not perfect, of course. It's slow, alien in many ways, lags behind in features of modern editors, and has a brutally steep learning curve, especially if you're not familiar with Lisps. It may take you years to appreciate it, and a lifetime to understand it. But that's OK. You don't need to understand all of it. As long as you start the journey, you can learn on the way, and your experience will keep improving.
I have been using Emacs for 35 years and I am still learning along the way. It has been the one constant across Solaris, Linux, Windows and macOS for all that time.
That's amazing! It would be very interesting to see what a config spanning 35 years looks like, and what your workflow is. If you could write a blog post about it, I'm sure others would appreciate it as well.
I suppose this goes for any Emacs user. There's so much we can learn and be inspired from by seeing how other people use it.
I have been using emacs for around 7 years, but it never worked for me as the main editor, it just sucked too bad compared to IDE-like features of other editors and actual IDEs. So I only used it for org-mode, doing an attempt to use it for something else every couple of years.
I'm currently in the process of trying this again, and I have to say things feel very different this time. By adding native tree-sitter and LSP support, the IDE-like features are outsourced to where they should be done. It wasn't perfect, but I had issues of the same degree or worse with other editors. A proprietary IDE still would beat it in stability and features, but the experience is _crazy good_ for free software.
What I like the most is the hacker mentality it encourages. When I see something I don't like, I don't go like "I wish they did it differently", I ask "well how do I change that?".
The only thing that feels truly outdated is single-threaded nature and blocking UI when long-running operation (like an update) is happening. And maybe non-smooth scroll (there is a package but it makes text jump).
Also the default keybindings used by Emacs to do basic text operations are available in many places thanks to GNU Readline and Cocoa, which makes the experience more pleasant.
That's true. Although TBH, I'm not a fan of Emacs' key bindings. Some short ones like `C-a`, `C-e` are fine, but more advanced ones are difficult to memorize and force your fingers in unnatural positions. I prefer modal UIs and find Vim's keybindings much easier to remember and type. So for me evil-mode has been essential, and aside from some quirks, it works as well as in Vim. Readline also supports vi mode, which I enable in any app that uses it.
It is true, but it's also not the case. The steep learning curve is flattened quite a bit by available "starter pack" configs and the amount of fresh articles. So you can get a functional editor and then gradually bend it to your needs.
Also, LLMs turned out to be quite good at generating working elisp and helping out in general.
Well, Emacs has been around for 40 years, and while it's difficult to gauge its popularity, there are many signs that suggest it has only been increasing. So I doubt it's going anywhere anytime soon.
Besides, I think there are also benefits from a tool having a steep learning curve. It indirectly acts as a filter, ensuring only people passionate about it stick around. It's not elitism, but it avoids scenarios like the Eternal September where the community gets flooded with new users and eventually never recovers. Software and services that become popular often stray from their original vision, and, with open source projects in particular, maintainers can be overwhelmed by support and feature requests from new users. Emacs doesn't have these problems, and hopefully never will.
Older things have died, and measuring isn't that difficult, surveys exist, and it's been ~consistently in the low single digit %.
> only people passionate about it stick around. It's not elitism
Yeah, that's exactly the faux elitist fantasy, except needlessly hardships also kills passion, and elite engineering ignites it, but being slow, unergonomic, and hard to change is the opposite of that. So you can't even get net win on 'passion', let alone some more directly relevant skills that help progressing development
I suppose so, but very few user applications have had the same longevity. There have been numerous text editors and word processors from the same era and after it that have disappeared, yet Emacs has endured. That has to mean something.
> measuring isn't that difficult, surveys exist, and it's been ~consistently in the low single digit %.
Surveys are not a good way of measuring the health of a specific project. Not all users will respond, and the percentages are skewed by the number of participants and popularity of other options.
A better way, though still inaccurate, would be to look at the amount of activity in the project's repository, the number of contributors, and the number of packages written in Elisp over time.
Emacs' official repo doesn't keep track of such statistics, but the GitHub mirror[1] shows signs of a very healthy project. You could also check package stats[2] or the amount of Elisp projects on GH[3], and compare them to Wayback Machine snapshots from a few years ago, and notice that they keep increasing.
These are all signs that Emacs is not going anywhere. The slow but steady growth is the positive aspect I was referring to earlier. Explosive growth is not good for an OSS project.
> Yeah, that's exactly the faux elitist fantasy ...
I mean, you're entitled to your opinion, but I haven't noticed any elitism in the Emacs community. It's mostly a bunch of hackers and tinkerers who are passionate about software and improving their workflow, as you can see from this article and comments here. There's no gatekeeping since anyone is free to use Emacs how they want to use it. Help and documentation is widely available, including within Emacs itself.
So I think you have the wrong idea and an axe to grind for some reason, which I can't really help you with. Cheers!
The model of computer use that appeals to me are the one that in theory have a simple system, but the real goal is for you to have a tool that fits your needs. So far it includes the BSDs (Unix), Emacs, and Smalltalk. I've not tried Plan 9 yet.
The more I'm learning more about the above, the more I'm believing that most computer problems has been solved since a long time and the focus should be on improving and creating new tools, not reinventing them.
PS: Spreadsheets are nice too, but they're still lacking the surrounding helpers that would make them great. There's VBA in excel, but I'm thinking about more like dynamic table that's linked to an endpoint or some commands (Unix's ps). I haven't explored tools like Airbase to see if they fit that vision.
> There's VBA in excel, but I'm thinking about more like dynamic table that's linked to an endpoint
I believe Excel has PowerBI for this purpose.
Which Airbase tool are you referring to?
My bad. I was referring instead to airtable. It’s SaaS, but I’m talking more about the concepts
Yes! Recent personal hacks with advice interactively programmed with the help of Claude 4.1 chat session running in Emacs.
I used IntelliJ happily for 10 years (I was a heavy Emacs user for 10 years before that). While it's true that some things are a little less convenient (I don't use LSP), knowing that I can tailor things exactly to my tastes is a serious breath of fresh air.It used to be I mostly used IntelliJ for work/OSS and Emacs for org-mode. Now the situation is likely reversed. Emacs for work/OSS and IntelliJ only if I need step debugging/global refactoring.
Having used emacs for many years, OP's description of "doing things wrong" is exactly the way I use emacs.
I seldom care about the inner workings of emacs and will do the absolute minimum to get it to work the way I want and then move on. I'm reminded over and over again that Emacs patinas really nicely with poorly written elisp in an init file over time.
Case in point, I found that org-export is super slow. After profiling it, I found the slow function, copied it, removed the slow part, and advice-add it right back in there[0]. Might this break some other deeply intertwined behavior someplace else? Probably. Does it matter if I'm the only one using it? Nope.
[0]https://github.com/alexkehayias/emacs.d/blob/master/init.el#...
I've got a handful of little personal optimizations like this, too, they're great
> Does it matter if I'm the only one using it?
Yes, you yourself can also suffer from that breakage, and worst of all, might no even notice it right away, so have a period of silent issues
That’s directly true of all FOSS. Any time you fork something, you have to keep adapting to changes in upstream.
This isn't about adapting to future changes, but noticing breakage in the current system.
But also, even in FOSS there can be projects that value stability and isolation, so if you fix some plugin that misbehaves you don't need to adapt because the underlying editor APIs that plugin relied on are stable and also isolated in a way where your changes can't break other users
Eh, Emacs isn't really a system where broken behaviour goes unnoticed. It either works as you expect or something isn't working correctly.
There is no magical system that can ensure no bug goes unnoticed
> or something isn't working correctly.
the issue isn't whether a bug exists, it's whether/when you notice this
You're missing emacs insane observability and tight feedback loops.
Why did that magic observability didn't help answer this simple question?
> Might this break some other deeply intertwined behavior someplace else? Probably
Learning and using Emacs is possibly the activity with the highest ROI over time you can do if you work with text for a living. Maybe even if you don't.
Every time you modify it, you are improving your workflow. Those changes compound over time so that the system is always familiar, which makes interacting with text, the filesystem, network, and anything else you can manipulate with Elisp, that much easier, faster, and more comfortable. What you end up with is a system that is unique to you. A system that does what you want the way you want it, and never changes unless you want it to. In a world where software constantly changes and breaks, where new editors appear and disappear, using your own version of Emacs is incredibly comforting. There are no surprises, no rugpulls, no radical UI redesigns, no sneaky telemetry or tracking, no ads, no nagware, and so on. Anything you don't like can be removed, changed, or improved.
It's not perfect, of course. It's slow, alien in many ways, lags behind in features of modern editors, and has a brutally steep learning curve, especially if you're not familiar with Lisps. It may take you years to appreciate it, and a lifetime to understand it. But that's OK. You don't need to understand all of it. As long as you start the journey, you can learn on the way, and your experience will keep improving.
I have been using Emacs for 35 years and I am still learning along the way. It has been the one constant across Solaris, Linux, Windows and macOS for all that time.
That's amazing! It would be very interesting to see what a config spanning 35 years looks like, and what your workflow is. If you could write a blog post about it, I'm sure others would appreciate it as well.
I suppose this goes for any Emacs user. There's so much we can learn and be inspired from by seeing how other people use it.
Emacs takes a lifetime to learn. The sooner you start the longer it takes!
> lags behind in features of modern editors
I have been using emacs for around 7 years, but it never worked for me as the main editor, it just sucked too bad compared to IDE-like features of other editors and actual IDEs. So I only used it for org-mode, doing an attempt to use it for something else every couple of years.
I'm currently in the process of trying this again, and I have to say things feel very different this time. By adding native tree-sitter and LSP support, the IDE-like features are outsourced to where they should be done. It wasn't perfect, but I had issues of the same degree or worse with other editors. A proprietary IDE still would beat it in stability and features, but the experience is _crazy good_ for free software.
What I like the most is the hacker mentality it encourages. When I see something I don't like, I don't go like "I wish they did it differently", I ask "well how do I change that?".
The only thing that feels truly outdated is single-threaded nature and blocking UI when long-running operation (like an update) is happening. And maybe non-smooth scroll (there is a package but it makes text jump).
Also the default keybindings used by Emacs to do basic text operations are available in many places thanks to GNU Readline and Cocoa, which makes the experience more pleasant.
That's true. Although TBH, I'm not a fan of Emacs' key bindings. Some short ones like `C-a`, `C-e` are fine, but more advanced ones are difficult to memorize and force your fingers in unnatural positions. I prefer modal UIs and find Vim's keybindings much easier to remember and type. So for me evil-mode has been essential, and aside from some quirks, it works as well as in Vim. Readline also supports vi mode, which I enable in any app that uses it.
> brutally steep learning curve.... It may take you years to appreciate it, and a lifetime to understand it. But that's OK.
It isn't, that's how apps decline in popularity and eventually die, thus decreasing the value of the huge amount of time you've invested
It is true, but it's also not the case. The steep learning curve is flattened quite a bit by available "starter pack" configs and the amount of fresh articles. So you can get a functional editor and then gradually bend it to your needs. Also, LLMs turned out to be quite good at generating working elisp and helping out in general.
Well, Emacs has been around for 40 years, and while it's difficult to gauge its popularity, there are many signs that suggest it has only been increasing. So I doubt it's going anywhere anytime soon.
Besides, I think there are also benefits from a tool having a steep learning curve. It indirectly acts as a filter, ensuring only people passionate about it stick around. It's not elitism, but it avoids scenarios like the Eternal September where the community gets flooded with new users and eventually never recovers. Software and services that become popular often stray from their original vision, and, with open source projects in particular, maintainers can be overwhelmed by support and feature requests from new users. Emacs doesn't have these problems, and hopefully never will.
Older things have died, and measuring isn't that difficult, surveys exist, and it's been ~consistently in the low single digit %.
> only people passionate about it stick around. It's not elitism
Yeah, that's exactly the faux elitist fantasy, except needlessly hardships also kills passion, and elite engineering ignites it, but being slow, unergonomic, and hard to change is the opposite of that. So you can't even get net win on 'passion', let alone some more directly relevant skills that help progressing development
> Older things have died
I suppose so, but very few user applications have had the same longevity. There have been numerous text editors and word processors from the same era and after it that have disappeared, yet Emacs has endured. That has to mean something.
> measuring isn't that difficult, surveys exist, and it's been ~consistently in the low single digit %.
Surveys are not a good way of measuring the health of a specific project. Not all users will respond, and the percentages are skewed by the number of participants and popularity of other options.
A better way, though still inaccurate, would be to look at the amount of activity in the project's repository, the number of contributors, and the number of packages written in Elisp over time.
Emacs' official repo doesn't keep track of such statistics, but the GitHub mirror[1] shows signs of a very healthy project. You could also check package stats[2] or the amount of Elisp projects on GH[3], and compare them to Wayback Machine snapshots from a few years ago, and notice that they keep increasing.
These are all signs that Emacs is not going anywhere. The slow but steady growth is the positive aspect I was referring to earlier. Explosive growth is not good for an OSS project.
> Yeah, that's exactly the faux elitist fantasy ...
I mean, you're entitled to your opinion, but I haven't noticed any elitism in the Emacs community. It's mostly a bunch of hackers and tinkerers who are passionate about software and improving their workflow, as you can see from this article and comments here. There's no gatekeeping since anyone is free to use Emacs how they want to use it. Help and documentation is widely available, including within Emacs itself.
So I think you have the wrong idea and an axe to grind for some reason, which I can't really help you with. Cheers!
[1]: https://github.com/emacs-mirror/emacs/pulse
[2]: https://emacsmirror.net/stats/compare.html#Summary
[3]: https://github.com/topics/elisp
[dead]