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.
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.
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.
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.
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.
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
> 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.
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
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.
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.
> 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.