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.
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 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.
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.
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.
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.
One thing I turn to VS Code these days for is Jupyter / Quarto notebooks.
It's not possible to have the same development workflow with Quarto and Org-babel since you can't run/rerun code chunks up to your current cell and automate figure management (for Org-babel).
I think these are not difficult to implement but these days I just want to use something that has these features out of the box and that notebook space is rapidly changing.
Emacs is quite alluring as an idea. I wish we had a "higher" level version of it that could support composing in proper browsers etc. Now I realize this is basically a tiling WM, but I guess I want more interoperability between programs and ability to pass data between them programmatically.
I will take the time to master Emacs when Emacs comes to meet me in the middle, and adopts what has been the industry-standard UI for a third of a century: CUA.
I would love someone to do an Emacs distro which integrated ErgoEmacs into it from the beginning:
https://ergoemacs.github.io/
for me the appeal of emacs is that it is so very cyberpunk and that it makes me feel like a hacker. seriously. also reducing the tool set appeals to my natural inclination towards minimalism.
I don't see why people are still using 1970s-era IDEs in 2023. Sure, it's a joke that emacs and vim users are at loggerheads, but name me one user of either who isn't a graybeard at this point. And specifically a graybeard who refuses to use more modern tools.
Long after you've migrated from your current favorite IDE twice over, we'll still be using emacs.
Long after whatever company sponsoring development of your current favorite IDE enshitifies them twice over, we'll still be using emacs.
Long after you relearn your IDE workflows twice over, we'll still be using emacs.
And emacs keeps evolving and can handle modern development just fine (except for the most garden-walled ones, and even then...), while not breaking our brains all the time with so many changes and migrations and trend changes.
We want to keep using our tools and get work done, not keep up with the Joneses.
Because it's thought out and polished by decades of use.
Because it's extensible.
Your very question, "why are people using an IDE from 1970s in 2023" should provoke some thought. Assuming that these people are not crazy (a lot of them is rather smart and rational), what us so good about Emacs (or Vim) to make it still a preferred choice?
I'm not sure what you mean by graybeard, but I started developing software 5 years ago. Started using emacs 3 years ago (magit). Wrote my own 1000 line emacs config 1 year ago.
I am in my early 20s and started using Emacs when I was 18. The reason I use Emacs instead of a more "modern" tool is because nothing else comes close in terms of ease of extensibility.
I would be interested to hear if you know of any modern editors where extending my editor is as easy as writing one line and running "eval-buffer".
I'm not a graybeard, I'm 28 and I've been using Emacs since I was 15. In that time, in my circle, I've seen notepad++, sublime, atom etc. all come and go. Of course everyone at work uses VS Code, in 2 years it will be New Editor by XYZ Corp.
Being old doesn't imply something is bad. Should we be asking what Emacs and Vim have done right so that they're still being used 50 years later?
I think you probably don't know emacs if you think no one should find it useful.
I highly recommend you give it a go. It may not become your main IDE, but I can guarantee that you'll find it very useful for a multitude of tasks, like a lighter text editor, quick REPL, RSS feed reader, binary file reader, org mode (like an organizer of tasks/notes/literal programming etc), magit (the amazing git client), grepping and navigating easily between search result files... and so many other things.
> I don't see why people are still using 1970s-era IDEs in 2023.
Because it works perfectly fine? So your reasoning is because is old is bad. That software that old still is being heavily used today is a testament that these tools have something that definitely the latest craze out there don't. And no, I'm not a greybeard, I'm in my 40's and been using VIM since I don't know when, probably more than 15 years for sure.
I'm not an old greybeard (in my 20s) and I solely use Emacs. What's "modern tools"? Emacs has everything; with the Language Server Protocol it is exactly like VS Code and the like, with autocomplete, find definitions, native tree-sitter support. It can even read PDFs, images, man/info pages, browse the web. I don't see any advantage that VS Code has over Emacs.
Maybe for whatever work you do your IDE works better for you.
In my case, I mostly code in C++. I've tried JetBrains' IDEs and it drives me insane how slow they are to index and I often get freezes when working on really large codebases.
The same applies to Visual Studio (not vscode).
vscode drives me insane with the amount of dumb notifications it keeps popping up. But I can concede that for most people it works well enough. It also doesn't perform nearly as well as Sublime Text. Working on really large codebases is a PITA with vscode.
If I need autocomplete (which I actually don't like that much), LSP works well for my needs.
[+] [-] lbj|2 years ago|reply
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.
[+] [-] onehair|2 years ago|reply
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.
[+] [-] microtonal|2 years ago|reply
https://github.com/doomemacs/doomemacs
[+] [-] yawpitch|2 years ago|reply
[+] [-] harrygeez|2 years ago|reply
[+] [-] anonuser123456|2 years ago|reply
[+] [-] chungy|2 years ago|reply
[+] [-] PurpleRamen|2 years ago|reply
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.
[+] [-] ak_111|2 years ago|reply
[+] [-] sleiben|2 years ago|reply
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
[+] [-] KolenCh|2 years ago|reply
(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)
[+] [-] tmtvl|2 years ago|reply
[+] [-] b5n|2 years ago|reply
From OP of your link: http://xahlee.info/kbd/i2/palm_control_key_youngstabber_2013...
[+] [-] gumby|2 years ago|reply
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.
[+] [-] hooloovoo_zoo|2 years ago|reply
[+] [-] submeta|2 years ago|reply
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.
[+] [-] beebmam|2 years ago|reply
[+] [-] aguynamedben|2 years ago|reply
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.
[+] [-] waynesonfire|2 years ago|reply
[+] [-] al_be_back|2 years ago|reply
Tempted by the 29% discount on the book, Mastering Emacs is a well-polished emacs blog
[+] [-] xormapmap|2 years ago|reply
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.
[+] [-] helmut_hed|2 years ago|reply
[+] [-] samuell|2 years ago|reply
(I'm a Vim user, but have sometimes half-pondered the thought of getting into Emacs, (using evil-mode of course), for the org-mode & co)
[+] [-] hatmatrix|2 years ago|reply
One thing I turn to VS Code these days for is Jupyter / Quarto notebooks.
It's not possible to have the same development workflow with Quarto and Org-babel since you can't run/rerun code chunks up to your current cell and automate figure management (for Org-babel).
I think these are not difficult to implement but these days I just want to use something that has these features out of the box and that notebook space is rapidly changing.
[+] [-] d0mine|2 years ago|reply
No issues with plotting figures in emacs-jupyter
https://github.com/emacs-jupyter/jupyter#org-mode-source-blo...
[+] [-] helmut_hed|2 years ago|reply
[+] [-] MassiveBonk51|2 years ago|reply
[+] [-] mkesper|2 years ago|reply
[+] [-] lproven|2 years ago|reply
I would love someone to do an Emacs distro which integrated ErgoEmacs into it from the beginning: https://ergoemacs.github.io/
No, CUA-mode is not enough.
[+] [-] omaranto|2 years ago|reply
[+] [-] 2-718-281-828|2 years ago|reply
for me the appeal of emacs is that it is so very cyberpunk and that it makes me feel like a hacker. seriously. also reducing the tool set appeals to my natural inclination towards minimalism.
[+] [-] shaunxcode|2 years ago|reply
[+] [-] RustyRussell|2 years ago|reply
[+] [-] psunavy03|2 years ago|reply
[+] [-] weikju|2 years ago|reply
Long after whatever company sponsoring development of your current favorite IDE enshitifies them twice over, we'll still be using emacs.
Long after you relearn your IDE workflows twice over, we'll still be using emacs.
And emacs keeps evolving and can handle modern development just fine (except for the most garden-walled ones, and even then...), while not breaking our brains all the time with so many changes and migrations and trend changes.
We want to keep using our tools and get work done, not keep up with the Joneses.
[+] [-] nine_k|2 years ago|reply
Because it's thought out and polished by decades of use.
Because it's extensible.
Your very question, "why are people using an IDE from 1970s in 2023" should provoke some thought. Assuming that these people are not crazy (a lot of them is rather smart and rational), what us so good about Emacs (or Vim) to make it still a preferred choice?
[+] [-] b0afc375b5|2 years ago|reply
I'm in my late 20s.
[+] [-] fayalalebrun|2 years ago|reply
I would be interested to hear if you know of any modern editors where extending my editor is as easy as writing one line and running "eval-buffer".
[+] [-] franticgecko3|2 years ago|reply
Being old doesn't imply something is bad. Should we be asking what Emacs and Vim have done right so that they're still being used 50 years later?
[+] [-] marginalia_nu|2 years ago|reply
[+] [-] brabel|2 years ago|reply
[+] [-] liendolucas|2 years ago|reply
Because it works perfectly fine? So your reasoning is because is old is bad. That software that old still is being heavily used today is a testament that these tools have something that definitely the latest craze out there don't. And no, I'm not a greybeard, I'm in my 40's and been using VIM since I don't know when, probably more than 15 years for sure.
[+] [-] alex_smart|2 years ago|reply
There is not a single modern tool that beats Emacs in ease of customizability and extension.
[+] [-] EFreethought|2 years ago|reply
[+] [-] botanical|2 years ago|reply
PS. Try Doom Emacs and evil-mode:
https://github.com/doomemacs/doomemacs/
[+] [-] TonyStr|2 years ago|reply
[+] [-] _trackno5|2 years ago|reply
Maybe for whatever work you do your IDE works better for you.
In my case, I mostly code in C++. I've tried JetBrains' IDEs and it drives me insane how slow they are to index and I often get freezes when working on really large codebases.
The same applies to Visual Studio (not vscode).
vscode drives me insane with the amount of dumb notifications it keeps popping up. But I can concede that for most people it works well enough. It also doesn't perform nearly as well as Sublime Text. Working on really large codebases is a PITA with vscode.
If I need autocomplete (which I actually don't like that much), LSP works well for my needs.
[+] [-] helmut_hed|2 years ago|reply
[+] [-] j7ake|2 years ago|reply
[+] [-] natsucks|2 years ago|reply