It's crazy that here in 2023, Emacs is still the absolute beast when it comes to developer productivity. I had a colleague review one of my workflows the other week and after a minute or so he said "Whoa, I would have been in 5 different tools by now".
If you're not into Emacs, I suggest you give it a whirl. For most development, nothing else will get you close to the joy and productivity that a well configured Emacs can.
Well, that's the real issue for me. I spent a month an a half working on "configuring" NeoVim. I got it to a somewhat ready to use state for my usual workflows. But I still had a big pile of tasks in my backlog to actually get it finally 100% mine.
Then I discovered Helix, which doesn't need any configuration, no plugins to play around with. Builtin LSP, Builtin Fuzzy Finding of files, TreeSitter and the list goes on.
Even though it's still not fully checking all the boxes I need to have a 1 to 1 mapping of my previous workflows to what Helix offers. I find not having to build my own editor out of the Lego pieces and always needing to improve what it can offer me, makes the editor actually enjoyable.
IMO, VIM, NeoVIM and Emacs should start looking into implementing a bit more than just the barebones, some of these new features that people are accustomed to in 2023, and more and more will flock to these good editors.
I'll admit I didn't look into it, but Helix sounds like something like LunarVim (https://www.lunarvim.org/)
Personally I much prefer that the editor NOT ship with something like that by default, especially when it's so easy to set up. I have several different vim config I use, including a pretty bare-bones one for headless systems, and I much prefer the ability to customize something very specifically.
Build tools that can compose together, rather than a single do-it-all tool. That is the power of the low level editors vs IDE's.
a few years ago (~2018?) I got excited about trying Org, and installed Doom Emacs on my (~18mo) old rMBP and it was slow-to-unusable. After ~30m of unproductive debug, i went back to vimwiki. The onboarding even with a distribution can be problematic.
I recently made some big changes to my Emacs config to incorporate new tooling like LSP into my workflow. It turned into quite an extensive change as I re-evaluated many extensions and replaced some with newer alternatives. Took a few evenings.
But I hadn't touched my config for three years before that! I've been using Emacs for 15 years and you definitely get to a point where you don't need to tweak it every day. 3 years is the kind of time some people would switch to a completely new editor. I have, in a way, except it still supports all the workflows that have become familiar over the years.
I installed spacemacs 5ish years ago and have added maybe 20 lines to my configuration since then. None in the past 4 years. It's really overstated the amount of maintenance that Emacs requires.
How is that true at all? I started with plain Emacs and gradually updated the configuration to the level of polish I wanted. Even if you're impatient and want something modern up front, the advise given is to start with a starter pack like Doom Emacs.
a huge part of it I will say is antithesis to current state of programming. Emacs is literally a live elisp interpreter with everything in global scope. You literally replace parts of the application in runtime.
As a long time emacs user, I can’t describe enough how much I love VS Code over emacs. And yes, I was a power user with all the fancy modes. And yes, I work entirely with Linux.
> "Whoa, I would have been in 5 different tools by now".
And those 5 tools would likely beat Emacs in their individual area.
At the end it's all a tradeoff between low fringe with somewhat good enough performance, or high fringe for stellar performance. Sometimes you need it, sometimes not.
I would say magit as an example. Single key presses for most actions. I often have that situation, when I share my screen and perform some commits and then people ask me whether I already commited X. I then think something like: "Uh, but I just did that, in front of your eyes." but then I remember the other workflow involving the normal command line or some clicky-gui kind of tool, that is just slower and is what others are used to.
Then maybe keyboard macros. Define anything you can input in a "tiling" way on your keyboard as a macro to let the editor perform it repeatedly. Approximate quote from coworker: "Sometimes you do things inconveniently, but what you do in Emacs was highly efficient."
Then running vterm inside emacs and searching and copying from the vterm buffers to use text elsewhere.
Of course org-mode as an extremely neat way of managing information and to do. I use it every day, a lot. I use it for notes, for to-do, for time tracking, for literate programming, for devops, for creative writing, and probably more.
Then the pain I get, when I see people closing their vscode, just to reopen it in another directory ...
Then the pain I see others have, when juggling a high number of editor tabs in intellij or vscode, instead of buffers that exist and can be switched to using keyboard shortcuts. I lost faith in tabs for code editors.
Magit is probably the easiest one for casual devs to appreciate.
"M-x magit" get a nice list of the status of the files in the current branch.
After you mark which ones you want to keep by moving up and down pressing s(tage) u(nstage) you just press "c c" and write your commit message. Then you press P and your git repo is up to date.
At a previous job the head engineer flagged the number of commits I was making as an issue since I must be wasting a lot of time pushing incremental changes. When I showed him that it took me about as long to push changes to my branch as it did to save the file he was flabbergasted that one could use git without pain.
In addition things other people have mentioned, like magit, I would add org-capture as a good example. Let's say I'm busy at work in a buffer and a thought comes to mind: "I could refactor that other module using this code". Instead of doing it immediately and breaking my flow, I press C-c c, select "todo", type "refactor that other module", perhaps add a tag, a category etc. then C-c C-c and it's filed away.
What's really important about all of this is, it's all Emacs. Every magit buffer, every org-capture buffer, it's all just Emacs buffers and they're all configured the way you like. If you need to do a regexp find and replace while you're capturing a note, you can. If you make a typo in a note, in a commit message, in an email or anything else, it's spell checked and you can correct it with the same key you always do. This integration is the real magic.
In this particular example, I was documenting my investigation into a defect. I was jotting down notes in Org-mode (1. note-taker). Those notes included SQL scripts which evaluate directly in the note-file (2. ejc-sql / replacing dbbeaver), letting the next user see which result I got from the queries and the ability to re-run the queries (C-c C-c). Some of the results returned large jsonb blobs, which were made readable with M-x json-prettify (3. replacing some online json prettifier). The git stuff (branching, making a pull request, updating it) was handled using Magit/forge (replacing git/lazygit). And ofc the code-editing replaces (5) whatever IDE you could otherwise use.
I saw people (in their 30s) using emacs for almost everything. Coding, reading mails, organizing their todos and so on. It was impressive to see their workflow.
Nit: It's a proper noun "Emacs" unless you're maybe referring to the executable "emacs", but at any rate the eMac was a computer sold by Apple in the education sector, and eMacs is the plural of that. Your iOS device is likely autocorrecting to that spelling, because to Apple, what else could you possibly be referring to?
In 2018 I switched from Vim (used for 5 years) to Emacs and I have no complaints about RSI/CT. It may be because I also learned to properly type with Dvorak at the same time. Unlike most Vim switchers I don't use Evil because modal editing just doesn't work for me. I always find myself having to change mode to do something and half the time the mode change doesn't take and shenanigans occur.
> The only thing which hold me back to really learn it, were the stories about repetitive strain injuries
Without wanting to be a troll, that's exactly what happened to me within 3 days after switching to emacs.. So I reluctantly terminated my emacs experiment early and switched back to vim..
You definitely needed to be on evil-mode or a framework (like Doom) based on it. The key bindings with ctl, alt, etc. are the least important part of Emacs but sadly, the part everyone thinks of first...
I feel like beginners should not read things like this. Just use the tool as little customised as possible, and be comfortable with it. Then look at making it more comfortable or more capable. If an enthusiast starts you down the customisation path up front, it's surely overwhelming.
When I learned emacs I just learned the tiny handful of motion commands: fwd, back, up down, by character, line, paragraph, code unit; plus opening and saving files -- basically the same power of Atom or Sublime or such. Then because of how emacs works I'd learn a new command from time to time and wonder how I lived without it. Even now 45 years later, I learn a new capability every few weeks, though of course Emacs is a lot more capable than it used to be!
A book like this is great, of course, once you're already comfortable with it.
Year after year I find myself using vscode instead of emacs for almost everything. Until org-mode support in vscode improves, I'll keep using emacs for that.
I keep trying VS Code, but I hate how when I split the screen three wide ("splits") it wants to open "editors" in each of the columns, even if it's the same file. I want a "buffer" like Emacs has that can be called up into any of the "splits" without reopening the file.
I disable the tabs display, but when I visit a file in each of the three columns (i.e. what in Emacs would be calling a buffer into a window) I end up with the same file open three different times, once for each split. Then the fast switcher just gets full of dupes. BLAH!
I really wish VS Code used the Emacs model of completely disjoined (a) buffers, (b) windows, (c) frames, but instead there's a hierarchical approach of Splits -> Editors.
I've dug into VS Code issues about this, and it seems the hierarchy between Splits -> Editors is a strong parent-child relationship embedded deeply within VS Code's model and is unlikely to change.
While Emacs is opinionated in its own way, it is extremely configurable, programmable, modifiable, customizable to ones needs. I guess it will take a long long time, until vscode is as modifiable as Emacs, if ever. And maybe that is not vscode's goal anyway.
This is my final quibble with VSCode as well - except I'm coming from Vim. I've hunted high and low through the settings - if anyone from the VSCode team is reading this, there's not another feature that's more vital to match vim/Emacs utility!
I'm a long time vim user who tried Emacs for a good few months. I started out with a minimal config and just got used to it out of the box, and over time evolved to using something more like evil mode and packages for everything.
The things that drove me back to vim were basically:
- Poor mercurial support. Monky is supposed to be like Magit but lacked support for staging individual hunks or any of the hg evolution commands. This forced me to use terminal modes which...
- ...The terminal modes are absolutely atrocious half baked pieces of crap. The only advice I really got on this was that using the terminal modes is "not the emacs way".
- I found it to be very opinionated about the style of C code I was writing. It tries to automatically indent things in very specific ways and god forbid you want to change the level of indentation of a block. You can change the way emacs indents your code in your config, but again, god forbid you ever want to do something slightly different to your config.
- Working with panes (windows), buffers, tabs etc. is a pain. You close a buffer and it disappears from the screen and is actually still open, and it pops up again when you wanted to go to something else.
This sounds like a bad review but I did for the most part enjoy using it. I just liked vim with tmux more.
Re: the C code, Emacs will happily let you ignore your own config settings. Just turn off anything labeled "electric" and nothing will happen automatically. And don't press tab, that will reindent the current line.
Readit News
If you're not into Emacs, I suggest you give it a whirl. For most development, nothing else will get you close to the joy and productivity that a well configured Emacs can.
Well, that's the real issue for me. I spent a month an a half working on "configuring" NeoVim. I got it to a somewhat ready to use state for my usual workflows. But I still had a big pile of tasks in my backlog to actually get it finally 100% mine.
Then I discovered Helix, which doesn't need any configuration, no plugins to play around with. Builtin LSP, Builtin Fuzzy Finding of files, TreeSitter and the list goes on.
Even though it's still not fully checking all the boxes I need to have a 1 to 1 mapping of my previous workflows to what Helix offers. I find not having to build my own editor out of the Lego pieces and always needing to improve what it can offer me, makes the editor actually enjoyable.
IMO, VIM, NeoVIM and Emacs should start looking into implementing a bit more than just the barebones, some of these new features that people are accustomed to in 2023, and more and more will flock to these good editors.
Personally I much prefer that the editor NOT ship with something like that by default, especially when it's so easy to set up. I have several different vim config I use, including a pretty bare-bones one for headless systems, and I much prefer the ability to customize something very specifically.
Build tools that can compose together, rather than a single do-it-all tool. That is the power of the low level editors vs IDE's.
Dead Comment
https://github.com/doomemacs/doomemacs
But I hadn't touched my config for three years before that! I've been using Emacs for 15 years and you definitely get to a point where you don't need to tweak it every day. 3 years is the kind of time some people would switch to a completely new editor. I have, in a way, except it still supports all the workflows that have become familiar over the years.
And those 5 tools would likely beat Emacs in their individual area.
At the end it's all a tradeoff between low fringe with somewhat good enough performance, or high fringe for stellar performance. Sometimes you need it, sometimes not.
Then maybe keyboard macros. Define anything you can input in a "tiling" way on your keyboard as a macro to let the editor perform it repeatedly. Approximate quote from coworker: "Sometimes you do things inconveniently, but what you do in Emacs was highly efficient."
Then running vterm inside emacs and searching and copying from the vterm buffers to use text elsewhere.
Of course org-mode as an extremely neat way of managing information and to do. I use it every day, a lot. I use it for notes, for to-do, for time tracking, for literate programming, for devops, for creative writing, and probably more.
Then the pain I get, when I see people closing their vscode, just to reopen it in another directory ...
Then the pain I see others have, when juggling a high number of editor tabs in intellij or vscode, instead of buffers that exist and can be switched to using keyboard shortcuts. I lost faith in tabs for code editors.
"M-x magit" get a nice list of the status of the files in the current branch.
After you mark which ones you want to keep by moving up and down pressing s(tage) u(nstage) you just press "c c" and write your commit message. Then you press P and your git repo is up to date.
At a previous job the head engineer flagged the number of commits I was making as an issue since I must be wasting a lot of time pushing incremental changes. When I showed him that it took me about as long to push changes to my branch as it did to save the file he was flabbergasted that one could use git without pain.
What's really important about all of this is, it's all Emacs. Every magit buffer, every org-capture buffer, it's all just Emacs buffers and they're all configured the way you like. If you need to do a regexp find and replace while you're capturing a note, you can. If you make a typo in a note, in a commit message, in an email or anything else, it's spell checked and you can correct it with the same key you always do. This integration is the real magic.
- Check to see that there isnt an MR outstanding bysomeone else ( using https://github.com/isamert/lab.el )
- (Optional) Cherry pick the commit from another stream where it may be fixed (magit-cherry-pick)
- Often massage the code (emacs cedet)
- Commit the code (magit)
- Submit a build (local built in code, elisp calling a local binary)
- Tag the build as the correct type (magit)
- Update the jira status (org-jira again)
- Wait for testing to complete, watch (eww)
- Email the requester on test results (wanderlust)
I also use:
- Some slack client for emacs (i dont remember the name)
- slime connected to nyxt brower so that I can automate some of the garbage that requires javascript.
The only thing which hold me back to really learn it, were the stories about repetitive strain injuries: https://news.ycombinator.com/item?id=36718793
(2 means eMacs specific, 1 means general. Sorry slightly confusing.)
Eg (1) macOS by default shares some eMacs key bindings.
(2) It is not originated from it because initially those keys aren't where they are now.
Solutions are
1. Remap the keys to solve (2) 2. Programmable keyboard (for every key bindings) to solve (1)
From OP of your link: http://xahlee.info/kbd/i2/palm_control_key_youngstabber_2013...
Without wanting to be a troll, that's exactly what happened to me within 3 days after switching to emacs.. So I reluctantly terminated my emacs experiment early and switched back to vim..
When I learned emacs I just learned the tiny handful of motion commands: fwd, back, up down, by character, line, paragraph, code unit; plus opening and saving files -- basically the same power of Atom or Sublime or such. Then because of how emacs works I'd learn a new command from time to time and wonder how I lived without it. Even now 45 years later, I learn a new capability every few weeks, though of course Emacs is a lot more capable than it used to be!
A book like this is great, of course, once you're already comfortable with it.
Currently, I rely on VS Code for coding, but turn to Emacs for text editing, macros, and text transformation with Elisp.
For a fast track to mastering Emacs, Mickey's book is a must-read.
I disable the tabs display, but when I visit a file in each of the three columns (i.e. what in Emacs would be calling a buffer into a window) I end up with the same file open three different times, once for each split. Then the fast switcher just gets full of dupes. BLAH!
I really wish VS Code used the Emacs model of completely disjoined (a) buffers, (b) windows, (c) frames, but instead there's a hierarchical approach of Splits -> Editors.
I've dug into VS Code issues about this, and it seems the hierarchy between Splits -> Editors is a strong parent-child relationship embedded deeply within VS Code's model and is unlikely to change.
And that's why I can't switch. That and magit.
Tempted by the 29% discount on the book, Mastering Emacs is a well-polished emacs blog
The things that drove me back to vim were basically:
- Poor mercurial support. Monky is supposed to be like Magit but lacked support for staging individual hunks or any of the hg evolution commands. This forced me to use terminal modes which...
- ...The terminal modes are absolutely atrocious half baked pieces of crap. The only advice I really got on this was that using the terminal modes is "not the emacs way".
- I found it to be very opinionated about the style of C code I was writing. It tries to automatically indent things in very specific ways and god forbid you want to change the level of indentation of a block. You can change the way emacs indents your code in your config, but again, god forbid you ever want to do something slightly different to your config.
- Working with panes (windows), buffers, tabs etc. is a pain. You close a buffer and it disappears from the screen and is actually still open, and it pops up again when you wanted to go to something else.
This sounds like a bad review but I did for the most part enjoy using it. I just liked vim with tmux more.