> If your time is so limited, eliminating toil seems essential.
The counter point to this is usually:
What exactly is your toil as a professional software developer (or associated profession) that is eliminated with a "better"[1] editor in 2023?
Refactoring is more powerful with an IDE, for mainstream languages. For non-mainstream languages 95% of what Emacs enables can be done using multi-cursors and a macro language built in to the editor, and we're in 2023. Those kinds of editors are a dime a dozen :-)
Editing data dumps or whatever is probably better with an advanced editor (I generally use Vim for that). But it's such a rare occurrence.
Writing code is super easy in an IDE.
Most of my toil is unnecessary meetings, unnecessary reporting, unnecessary social stuff. Emacs can't help with any of that.
* * *
[1] To note, "better" is strictly a claim. I'm quite sure there's no peer reviewed study that can prove conclusively that Emacs/Vim users are more productive than non-Emacs/Vim users, just due to their usage of Emacs/Vim.
The "toil" is anything involved in software development that's boring and repetitive. There's a computer right there that's for that stuf. My biggest frustrations come when I'm prevented from bringing the power of that computer to bear on a problem that isn't one of the ones envisioned or prioritised by the makers of my tools, and they didn't think to make it easy for me to extend them myself.
Emacs isn't an editor, it's a (very) rapid development environment for textual UI applications. Text editing is a large class of such applications but there are plenty of others.
Case in point: at work we use a job scheduler with a horrid web UI. I knocked something together in a couple of hours in emacs that eliminated that pain from my life and allowed me to explore our environments much more freely. If more of my colleagues used emacs they could share in the joy. I don't have anywhere near the time I would need to make something they could use without it.
Meetings, reporting and "social stuff" isn't much of an issue for me as I've been very clear in every interview I've had that I have no desire to take on managerial responsibilities at any stage of my career.
> Case in point: at work we use a job scheduler with a horrid web UI. I knocked something together in a couple of hours in emacs that eliminated that pain from my life and allowed me to explore our environments much more freely. If more of my colleagues used emacs they could share in the joy. I don't have anywhere near the time I would need to make something they could use without it.
Other devs would (and regularly do) just whip up something using shell scripts and command line tools, or write their own CLI/TUI/GUI/web service/app for the exact same thing. There are myriad viable ways to automate things.
> Meetings, reporting and "social stuff" isn't much of an issue for me as I've been very clear in every interview I've had that I have no desire to take on managerial responsibilities at any stage of my career.
Meetings, reporting and "social stuff" happen as an individual contributor because you need to sync with customers, peers, bosses, plus customers and bosses also expect you to report your progress. Social stuff isn't going out to lunch or dinner, it' just regular interaction or support.
I'm glad that you get what you want, not everyone does.
I'm just pointing out that there are many ways to happy coding and Emacs is just one of them.
A needlessly crabby response. I don't think anybody claimed emacs was the only way to code happily.
I was just explaining what the "toil" is in my life and how emacs materially alleviates it. The examples you give don't, in my experience, allow a useful interactive UI to be knocked together anywhere near as quickly as it can be done by an experienced user in emacs. YMMV - use whatever tools you like and manage your career how you please.
> Other devs would (and regularly do) just whip up something using shell scripts and command line tools, or write their own CLI/TUI/GUI/web service/app for the exact same thing.
The difference is time of development and flexibility of tge emacs result using the same universal plain text interface you use in emacs every day for me.
For non-mainstream languages 95% of what Emacs enables can be done using
multi-cursors and a macro language built in to the editor, and we're in
2023. Those kinds of editors are a dime a dozen :-)
Are they? Multi-cursors, sure, but what other editors have a macro language that combines the power and accessbility of emacs lisp? The only other one that comes close is vim, and, as many critiques as I have of emacs lisp, I can firmly state: it's a lot nicer to use than vimscript.
But other than emacs and vim, which other editors allow me to interactively automate portions of my editing workflow? All the other IDEs and editors that you've cited, like IntelliJ or VSCode require you to either find or write a package. That's a much bigger step than just interactively evaluating some lisp to do a one-off thing.
There are many text editors extensible in Lua or in Python. They generally don't allow messing with the innards as much (Firefox proved that's a double edge sword with its extension, it's not an unalloyed good).
And Emacs Lisp doesn't feel super accessible to most software developers under 40. Almost all its conventions come from a small little island, it's like marsupials in Australia, their own little parallel evolution.
> But other than emacs and vim, which other editors allow me to interactively automate portions of my editing workflow? All the other IDEs and editors that you've cited, like IntelliJ or VSCode require you to either find or write a package. That's a much bigger step than just interactively evaluating some lisp to do a one-off thing.
Devs generally write one-off or maybe reusable shell/Python/... scripts for that. But some of the examples I listed allow you to do a lot of that using Lua.
There are a ton of workflows out there, other devs don't just bang 2 rocks together because they can't automate everything <<inside>> the editor itself :-)
> And Emacs Lisp doesn't feel super accessible to most software developers under 40.
Or over 40 (I'm 42) :)
> Almost all its conventions come from a small little island, it's like marsupials in Australia, their own little parallel evolution.
This is a great analogy. And people forget that to program any system effeciently you need to know that system. Not necessarily inside-out, but good enough. A brief look at any emacs config will show you just how many weird and inconsistent things you have to contend with: major modes, minor modes, hooks, global variables, global functions, mode-specific global functions, special lists, non-special lists, and a myriad API calls and functions in between.
Wikipedia says that emacs has 10 000 (ten thousand) built-in commands [1] That's probably on par with JVM :)
The worst part for me is that I wanted a few "simple" UI tweaks with Emacs. I really wanted to use it.
But I wanted it to have a native tab bar and I wanted to move the command bar at the top, with dropdowns instead of "expand-ups" (turns out, I read right-to-left, top-down, not right-to-left, bottom-up. You can't have either of those, in the world's most extensible editor :-(
Emacs has had tab-bar-mode since 27.1 and tab-line-mode since 27.2. As for the drop-down minibuffer (I suspect that's what you mean by "command bar"), you can use something like vertico-posframe* and put it at the top like so:
> but what other editors have a macro language that combines the power and accessbility of emacs lisp?
Is it accessible? Why would I want to spend time learning the idiosyncrasies of a 40-year-old editor to write something that I might use once in a blue moon?
The counter point to this is usually:
What exactly is your toil as a professional software developer (or associated profession) that is eliminated with a "better"[1] editor in 2023?
Refactoring is more powerful with an IDE, for mainstream languages. For non-mainstream languages 95% of what Emacs enables can be done using multi-cursors and a macro language built in to the editor, and we're in 2023. Those kinds of editors are a dime a dozen :-)
Editing data dumps or whatever is probably better with an advanced editor (I generally use Vim for that). But it's such a rare occurrence.
Writing code is super easy in an IDE.
Most of my toil is unnecessary meetings, unnecessary reporting, unnecessary social stuff. Emacs can't help with any of that.
* * *
[1] To note, "better" is strictly a claim. I'm quite sure there's no peer reviewed study that can prove conclusively that Emacs/Vim users are more productive than non-Emacs/Vim users, just due to their usage of Emacs/Vim.