I wrote this piece because I found the topic... hilarious. Not because of this specific question, but because I'm witnessing how highly-positioned people (at work) are "discovering" command line tools now that they are "forced" to interact with CLI-based coding agents--and then trying to demonstrate how useful their new discoveries are. tmux is the shining example so far, and I'm waiting for them to realize that... Vim and Emacs are a thing too.
You know, these tools have been with us for many years, and if you ask the "advanced 10x developers" at your company, they'll likely tell you that they use them. But these tools are often disregarded as "haha, that's ancient stuff; let's move to the web!!11". You know, maybe there was a reason for those developers sticking to these tools! ;P </rant>
I'm witnessing how highly-positioned people (at work) are "discovering" command line tools now that they are "forced" to interact with CLI-based coding agents
This does feel like the one silver lining of the slop bubble, plain text is once again becoming a viable and important medium, both in terms of CLI becoming more common and a lot of newly written down oral knowledge (as long as it's human-sourced, of course). I hope once we're through the current predicament, we can keep these good parts.
Absolutely. People used to laugh at me for creating CLI wrappers around things and small binaries that automated parts of a workflow. They thought a GUI or web application was better suited. Hah!
CLI tools have always had the benefit that they're so easily embedded in scripts, recursively, building powerful abstractions. That's essentially what LLMs rely on too.
I don't. I deliberately install emacs-nox on all my machines to keep the local experience the same as the remote one.
I've been using emacs on essentially everything since a few things happened at almost the same time in the mid to late 90s:
Linux started to spread and I ran MkLinux (1995) part time on my Mac
I got a SPARC ELC the local university was throwing out for $50 plus another $50 for the guy to do a clean install of Solaris on it. So I could leave the Mac in MacOS... 1996 I think.
full time on a end-of-life sale on an HP Pentium Pro 200 server when the Pentium II was out (apparently the Pentium Pro didn't like 16 bit code, so was considered a dog once the P II was out, but mine never saw any). Late 1997?
Sure, and I occasionally use the GUI too when I directly work on the local machine (which is rare). But the fact that I can use the exact same configuration in the shell is the key feature for me. I don't think any other editor, except Vim, offers this.
I mostly use the GUI, but mainly as a slightly prettier and nicer (scroll bar, gutters, 3d shading on the modeline, etc.) version of terminal Emacs. My config runs just as well on terminal Emacs, though, and I use that plenty too.
I'm perfectly happy to run Emacs over SSH. (Tramp works, but if I'm already SSH'd to a machine, I might as well stay there if I need to edit something.)
It’s been a while (I don’t use remote access in my current job) but I tended to ssh from within Emacs, using Eshell. It means I don’t have to care if the machines use zsh or bash, since Eshell abstracts away that difference. It also means I always have a local editor with my familiar config at my fingertips.
Eshell and tramp scares me a bit. For example, when I ssh in to a machine and run whoami, it returns the user of my laptop. If my pwd is on the remote machine and I run rm /XX, it's unclear if it removes /XX on my local machine or on the remote machine (I think it would remove /XX on the local machine?).
I think that would remove the local one. From my memory (and referencing an old SE post) the path to remote files would be something like: cd /ssh:example.com:/, so I would expect rm /ssh:example.com:/XX to remove /XX from the remote machine.
Huh. I've had problems specifically with SSH under Eshell. That's one of the few things I still use a regular terminal emulator for. Thanks for prodding me to invesigate more instead of giving up right away.
(Or do you mean file system operations through TRAMP rather than remote command execution?)
It's been a while, but I'm pretty sure I did a bit of both. After reviewing my question around running man in TRAMP Eshell session I am reminded that there could be some paper cuts in that area, but I'm sure they're not insurmountable. I would definitively use TRAMP again if I need to edit files on remote machines, but these days I deal with cattle rather than pets—and moreover am a dev in a company where only infra team has direct prod access.
I think the push to cli thing is maybe one additional reason, but I wouldn't bet on it being a major driver.
I've seen a lot of people - actually only a few if we're talking relative numbers - look at my terminal and say "oh that's cool can I try" and dig into the cli tools. A lot of people need to mess with this - e.g. get the docker thing built properly or authorisation of cloud tools or similar. But they do it in a terminal in Vs code and just jump back into the gui mode as soon as they're done.
I'm not saying this is wrong or anything, that's a perfectly good way to work. But to paraphrase your own post, the real power of cli isn't that one tool, it's all of them. The "Unix is my IDE" makes a lot more sense when you connect many unrelated tools and can do so with ease because they're built that way.
And even then, since it's all text, it's very easy to bind a complex workflow to a single green mouse target called "build" or something.
Again, not calling you out. My point is that I think that having to use the cli agents isn't that much of a reason for people to get into the command line, command line is.
Not fully disagreeing, just think it's not that big of an impulse.
look at my terminal and say "oh that's cool can I try" and dig into the cli tools.
I'd love to be able to say the same thing, but when people have seen me using or talking about CLI tools, they've usually smirked. That's why it bothers me that they now seem to be wanting to use these tools (while I still sense their smirk).
And no, based on what I see in my environment, the push for some CLI tools is entirely about agents. People around me are now forced to interact with Claude Code and want to run multiple instances of it in parallel. And they get lost because the previous heavy IDE tools they were given don't "scale" to these workflows.
Right... that's why, as I mentioned in another comment, I never run doom upgrade. I just nuke ~/.emacs.d/ and reinstall from scratch. I have been doing this a few times per month for a long time now and never ran into issues.
42 years, and I'm still customizing and learning Emacs. The only thing I can't figure out how to do in GNU Emacs is WYSIWYG HTML editing, so I'm working on an Emacs subset specifically for that purpose.
Count me in as someone that just started learning it!
I tried out Doom Emacs a few years ago and bounced off because the latency was noticeable enough to be annoying. I'm not sure if native compilation has made that a thing of the past, I'm in vanilla Emacs without anything configured yet so I don't think I would notice. I'm also running 30.2 from Nixpkgs, which I think enables native compilation by default.
I mostly don't care that I can do things like write email in Emacs. I just want an editor that I can mold, and that is capable if/when I want to learn a lisp (Janet, probably). Helix doesn't have plugins (yet), so I'm pretty much out of luck on the lisp front there. I also like the "everything is text" philosophy, but we'll see how I get on with that.
There's a few things that make learning it in 2026 kind of daunting:
There's literally decades of built up tribal knowledge about how to do things. If you read articles you'll see people throwing around package names, command names, etc. It's overwhelming when all I want to do is $THING. I've picked up Mastering Emacs for a guided learning path.
The fact that the built-in keybindings are...odd. I know you can rebind everything, it's just work. The other hard thing is that I built myself a split ergonomic keyboard and tailored the firmware for a more vim-style (Helix) workflow, where modifier keys aren't used as a core part of the workflow. I also switch between three different keyboards depending on machine and location: Macbook Pro, PC, and this custom one. That means I need to figure out some coherent set of keybindings that don't make my brain melt. The hjkl keys are in the same location on all of my keyboards. The Ctrl, etc keys are not.
If you're coming from Helix, maybe check out meow. It provides functionality out of the box that is like Kakoune and Helix (though I haven't personally used either so this is just from what I have heard) and tries to stay more out of your way.
I think the evil package which you have been recommended has the problem of taking over too many key-bindings and not playing nice with a lot of external packages (therefore needing lots of "adapter" packages). I find that meow for me has been very hands-off since I configured it once.
I need to figure out some coherent set of keybindings that don't make my brain melt.
So it turns out that things that make you feel like your brain is melting are actually quite good for maintaining cognitive capacity as you get older. The old “use it or lose it” aphorism applies.
We have to pick and choose when we spend our cycles so to speak, but our brain isn’t a bank, and not spending cycles at all leads to atrophy.
So don’t completely shun the brain melt. It’s a sign you are exercising your brain in a novel way and building more neuronal connections.
If you're having issues with the keybindings and you're a bit more familiar with vim, it might be worth having a look at evil. You'll probably hear admonitions that evil is for Vim refugees who don't want to learn the true Gospel of Emacs, but the True Gospel of Emacs® is that you use it the way that works best for you.
As a bit more to back up that point, I've been using Emacs since 1998 and was never a Vim aficionado. Around 2011, I started having some minor RSI issues and I decided to try different packages to help with that. I spent a few years heavily engaged in god mode, but it still felt clumsy. Then, just to prove that it wouldn't work, I tried evil, having never used vim before in my life. In a week, I was just as proficient with evil as I was with god mode. In a month, I was faster with evil than I had ever been with even the official Emacs bindings.
Now, coming back around to the True Gospel of Emacs®, that doesn't mean that there's anything wrong with using the default bindings. My wrists don't work, so my experience with them will not exactly match your own. You might also find joy in boon or meow. However, if evil does work for you, then don't feel one drop of guilt, because, while Emacs will change you, that will pale in comparison to the ways that Emacs will change for you.
I've been looking at split keyboards for a while now. Recently I started thinking about a custom one. What do people use in this area that is vim friendly?
I think starting out on vanilla Emacs is the right call, to learn where its rough edges are and where it ends. But when you feel comfortable, I can warmly recommand installing Evil as one of the first things you try from the package ecosystem. It gets you sane bindings in most places.
If you want a more Helix style experience in Emacs, take a good look at Meow. It's kind of a lot to take in, but it should be pretty straightforward to get things the way you want within that framework.
It really depends on how you configure Doom. It’s also been improving overtime in that regard. The best is obviously rolling your own but it is a lot of work and projects like doom do ease the ingress of new users
I used to know the native Emacs key bindings well-enough but never found them very natural, and they were not particularly discoverable. The way Doom Emacs works, with SPC as the prefix for almost all operations and with transient menus explaining possible completions when you pause, is pretty great. I've been able to discover functionality I didn't know existed, and these don't interfere at all with the Vim modal modes. So I'm finding the mixture of Vim modes for text editing + SPC combinations for Emacs operations to be a good balance.
One plus for Emacs-native keybindings, however, is that all the basic text-manipulation ones are shared with readline and even macOS. (Mind you, I found VSCode on macOS pretty nice because macOS propagated its native Emacs-like keybindings for text management and these didn't collide with the standard clipboard management ones. When I moved to Windows and now Linux, I could just not stand VSCode without the Vim plugin.)
with transient menus explaining possible completions when you pause, is pretty great
This is why in my public Emacs documentation I recommend only two changes to the Emacs default configuration to start with, and one of them is which-key-mode, which is in base Emacs and I suspect it's what Doom uses.
Given that many Emacs shortcuts are clustered around stuff like C-x and C-c, which-key-mode enables much of this discoverability you mention.
The other change I recommend is fido-vertical-mode, which means that M-x pops a substring search of commands instead of a bare command line interface. The UI also shows the shortcuts of matched commands, which also helps with discoverability.
(Unfortunately, there's a lot of Emacs-specific terminology [like yanking, etc.] which hampers discoverability. I wish Emacs standardized some kind of aliasing to more common terms.)
At some point I expect to show my daughter emacs, and when she responds in confusion and horror explain that "The tradition of all dead generations weighs like a nightmare on the brains of the living." I'm sure it'll go over well.
I'm a weirdo who uses Emacs for development, for writing, and for email, and have done so for about 15 years – yet I've never found the time or headspace to learn elisp. I don't actually know what I'm doing when I'm messing with my config file. That this is somehow still my most productive environment says something about how amazing that editor is :-)
Actually reading Mastering Emacs has been on my todo list for longer than I want to admit.
Beyond writing your config file, knowing how to write a little elisp can be amazing with regexp search-and-replace. In a replacement, you can write \, and then an elisp expression. So for example:
Increment all the integers: [0-9]+ → \,(1+ \#0)
Round all decimal numbers to two places: [0-9]+\.[0-9]* → \,(format "%.2f" \#0)
Capitalize all words immediately preceded by foo: foo \([a-z]+\) → foo \,(capitalize \1))
Within the elisp expression in the replacement, \1 etc. evaluate to the numbered capture group, interpreted as a string, while #1 etc. evaluates to the the capture group interpreted as a number.
You can do some crazy stuff, especially if you define a small function for more complex processing and then call it from the replacement expression like this. It can let you do search and replace with some smarts.
It's one of those cool Emacs tricks that I've never seen anywhere else, but comes in quite handy every now and then.
Honestly, I'm mostly in the same boat. I know a little bit of elisp via osmosis from updating/editing my configuration, but it's actually a bit embarrassing how little of the language I know.
I've at some point tried to use Helix because it sounds great (native Rust, simple configuration, no Elisp that I haven't grasped yet; I'm sold!). But then I get such an uncanny valley feeling due to the Kakoune-style shortcuts... and I still use Vim a lot for quick edits, so I think I just cannot make that switch...
I have flip-flopped between doom and (n)vim back and forth, but have "recently" mostly settled with neovim. Key issues for me while using emacs - and it is somehow hilarious to say - is pain to maintain. Upgrading doom frequently left me with only the nuclear option of completely reinstalling due to out-of-sync packages. Sure, I could've fixed it less "noob"y, but at some point you just stop caring and want your stuff to work. Can't afford configuration breakage and heavy editor-dependency when there is work to do.
Though, I do miss org-mode and just overall navigation in emacs.
Whenever I tried any of the more "modern" solutions, say VSCode, CLion or whatever, I have the same issue - and more! Now, I have to click around awkwardly instead of plain keyboard navigation, because they don't properly implement accessibility features. "vim" motions is a crippled version of the true thing.
Why neovim nowadays? It just works. Honestly, could say the same about emacs nowadays if I'd just spent 2 mins asking a coding agent to fix my config... oh well (:
Key issues for me while using emacs - and it is somehow hilarious to say - is pain to maintain.
I've tried doom's "update" feature sometimes and always had trouble.
Nowadays I just rm -rf ~/.emacs.d/ and set up doom from scratch (I keep ~/.doom.d/ under version control) every time I feel like upgrading or have to upgrade because Emacs gets upgraded. Never had issues with this flow.
My peeve with Doom/Spacemacs and other quirky chungus emacsen is exactly their disrespect to original keybindings. That makes communicating editor functionality to people using them somewhat frustrating.
I have been using Emacs for about a decade. The best part about Emacs is its malleability. Using something like Doom kinda take a hit on it, but still way better than VSCode or other editors. I am Vim to Emacs convert from the pre Neovim era and have been happy with Emacs since. In addition, now that we can ask LLMs can work with Emacs, I can ask an AI to fix any minor inconveniences that I have in my Editor and we are good.
Let me give you a small example. I wanted to update the order in which files show up in the file picker. Here is a small set of rules I wanted to apply:
mock files: -5 score
test files: -1 score
locality to current file: score based on how far
I could easily do this within Emacs with a couple of lines of elisp to hook into the file sorting logic and modify it in the running Emacs instance. Even better, I could explain this much to an LLM, give it emacsclient to evaluate elisp and I have it in 5minutes without even looking at the code. If you had to do the same within VSCode, I'm assuming you have to develop a separate plugin, but then now you are likely also responsible for creating your own popup menu. And to test it, you now have to load another VSCode instance with the plugin loaded. I hope you get my point.
A lot of the work I do would be almost impossible without Emacs. The custom modes I’ve written for editing my peculiar documents would be just a pain in any other editor.
Yes, me. But I’m probably not that common. I deal with a client at work that their entire business involves leveraging very large csv files and apparently nobody there seems to know how to open or review data in a 1gb file. They don’t even know what the head command is to give me the headers of a csv.
I've been considering switching back to Emacs after using (neo)vim for almost a decade but I'm not convinced that Emacs has/will have a strong anti-LLM policy for development and contributions. It seems like the only thing holding back the GNU community from using LLMs is FSF's verdict about the copyright situation of LLM generated code and I view the impact of LLMs on the environment and their relationship with copyright as the two weakest arguments one can take against LLMs.
I don't want to invest hundreds or thousands of hours on my text editor ((neo)vim) only to discover that its developers are using LLMs.
One thing that doesn't get talked about enough if the friction between TUI editors and the host operative system clipboard.
TUI editors predate desktop environment clipboards and because of that they have their own.
This is the main reason I never committed to TUI editors even though I make heavy usage of terminal emulators.
Other than that, I think VSCode does borrow a lot of ideas from emacs. It's philosophy has much in common with emacs'. Extendable, centered around text buffers rather than UI widgets, comes with a built in terminal that can be open both full screen and in a split buffer, and so on.
There's two counters to this: 1) idk about emacs, but vim actually can integrate with the host OS, though the key sequence is a bit awkward: "+ (or "* for X's PRIMARY). This works pretty ok on Windows, and on X it opens a new connection to the DISPLAY which is... ok, but has an annoying element in that I'm frequently migrating open terminal sessions between systems and this connection doesn't migrate with it. On my own setup, I modified vim to instead send a "request clipboard" escape sequence to the terminal, which is passed down and back up the chain through the OS, but it is a bit janky, vim did not want to do this and it is a hacky key rebind instead of a complete integration.
But if you mostly keep your sessions on the originating display, the built in thing works ok once you get used to the key sequence.
or 2) you can use the terminal emulator's integration. Shift+select to copy and middle click to paste. This is what I do most often and it works fine, with bracketed paste vim handles it fairly well. Selection can be janky since it is what is displayed in the emulator instead of the original buffer but still usually good enough.
It's not about being impossible. It obviously is possible. It's the horrible friction which vim/emacs user tend to underestimate but which 99%+ of the users would never bother to check.
I can use the arrow keys. Home and end keys, insert, delete, backspace, Ctrl+arrow, Ctrl+end, Ctrl+arrow, shift+arrow, shift+end, Ctrl+shift+end/home/arrow, Ctrl+a, Ctrl+x/c/v and so on, in any text area of any application and it all works reliability and seamlessly. Negating access to so brutally practical functionality is huge deal breaker.
Neackbeard grown solutions to mitigate such a big deal won't cut it. No offense. Sure, some guy has written this and that integration that is just a matter of installing this and that plugins and had edit 5 lines of elisp or vimscript that can be in a file in one of these five locations... But that that point you already lost the interest of maybe a couple extra nines of your potential market share which was already bellow 1%.
The momentum gravity pull of the desktop environment is just too strong.
[OP] jmmv | a day ago
I wrote this piece because I found the topic... hilarious. Not because of this specific question, but because I'm witnessing how highly-positioned people (at work) are "discovering" command line tools now that they are "forced" to interact with CLI-based coding agents--and then trying to demonstrate how useful their new discoveries are. tmux is the shining example so far, and I'm waiting for them to realize that... Vim and Emacs are a thing too.
You know, these tools have been with us for many years, and if you ask the "advanced 10x developers" at your company, they'll likely tell you that they use them. But these tools are often disregarded as "haha, that's ancient stuff; let's move to the web!!11". You know, maybe there was a reason for those developers sticking to these tools! ;P </rant>
nemin | a day ago
This does feel like the one silver lining of the slop bubble, plain text is once again becoming a viable and important medium, both in terms of CLI becoming more common and a lot of newly written down oral knowledge (as long as it's human-sourced, of course). I hope once we're through the current predicament, we can keep these good parts.
kqr | 14 hours ago
Absolutely. People used to laugh at me for creating CLI wrappers around things and small binaries that automated parts of a workflow. They thought a GUI or web application was better suited. Hah!
CLI tools have always had the benefit that they're so easily embedded in scripts, recursively, building powerful abstractions. That's essentially what LLMs rely on too.
thesadsre | a day ago
I think most Emacs users are using the GUI. I don't have the numbers, but I would bet it's the vast majority.
brucehoult | 18 hours ago
I don't. I deliberately install
emacs-noxon all my machines to keep the local experience the same as the remote one.I've been using emacs on essentially everything since a few things happened at almost the same time in the mid to late 90s:
Linux started to spread and I ran MkLinux (1995) part time on my Mac
I got a SPARC ELC the local university was throwing out for $50 plus another $50 for the guy to do a clean install of Solaris on it. So I could leave the Mac in MacOS... 1996 I think.
full time on a end-of-life sale on an HP Pentium Pro 200 server when the Pentium II was out (apparently the Pentium Pro didn't like 16 bit code, so was considered a dog once the P II was out, but mine never saw any). Late 1997?
Rhapsody (1997) -> OS X (2000)
stig | 15 hours ago
Have you tried Tramp? Saves you having to install Emacs & sync config to multiple machines, and lets you use GUI Emacs everywhere.
green7ea | an hour ago
I tried tramp a few times and it never stuck because it was too slow. Recently, I tried tramp-rpc and now I'm sold.
I would recommend trying tramp-rpc if have the patience to install it.
[OP] jmmv | 23 hours ago
Sure, and I occasionally use the GUI too when I directly work on the local machine (which is rare). But the fact that I can use the exact same configuration in the shell is the key feature for me. I don't think any other editor, except Vim, offers this.
Boojum | 13 hours ago
I mostly use the GUI, but mainly as a slightly prettier and nicer (scroll bar, gutters, 3d shading on the modeline, etc.) version of terminal Emacs. My config runs just as well on terminal Emacs, though, and I use that plenty too.
I'm perfectly happy to run Emacs over SSH. (Tramp works, but if I'm already SSH'd to a machine, I might as well stay there if I need to edit something.)
stig | 11 hours ago
It’s been a while (I don’t use remote access in my current job) but I tended to ssh from within Emacs, using Eshell. It means I don’t have to care if the machines use zsh or bash, since Eshell abstracts away that difference. It also means I always have a local editor with my familiar config at my fingertips.
mccd | 9 hours ago
Eshell and tramp scares me a bit. For example, when I ssh in to a machine and run whoami, it returns the user of my laptop. If my pwd is on the remote machine and I run
rm /XX, it's unclear if it removes/XXon my local machine or on the remote machine (I think it would remove/XXon the local machine?).stig | 3 hours ago
I think that would remove the local one. From my memory (and referencing an old SE post) the path to remote files would be something like:
cd /ssh:example.com:/, so I would expectrm /ssh:example.com:/XXto remove/XXfrom the remote machine.kqr | 10 hours ago
Huh. I've had problems specifically with SSH under Eshell. That's one of the few things I still use a regular terminal emulator for. Thanks for prodding me to invesigate more instead of giving up right away.
(Or do you mean file system operations through TRAMP rather than remote command execution?)
stig | 3 hours ago
It's been a while, but I'm pretty sure I did a bit of both. After reviewing my question around running
manin TRAMP Eshell session I am reminded that there could be some paper cuts in that area, but I'm sure they're not insurmountable. I would definitively use TRAMP again if I need to edit files on remote machines, but these days I deal with cattle rather than pets—and moreover am a dev in a company where only infra team has direct prod access.singpolyma | 8 hours ago
Really Emacs is a GUI. Even if you run it in a terminal it draws a GUI there
spudlyo | 5 hours ago
I think you have this exactly backwards.
zladuric | 15 hours ago
I think the push to cli thing is maybe one additional reason, but I wouldn't bet on it being a major driver.
I've seen a lot of people - actually only a few if we're talking relative numbers - look at my terminal and say "oh that's cool can I try" and dig into the cli tools. A lot of people need to mess with this - e.g. get the docker thing built properly or authorisation of cloud tools or similar. But they do it in a terminal in Vs code and just jump back into the gui mode as soon as they're done.
I'm not saying this is wrong or anything, that's a perfectly good way to work. But to paraphrase your own post, the real power of cli isn't that one tool, it's all of them. The "Unix is my IDE" makes a lot more sense when you connect many unrelated tools and can do so with ease because they're built that way.
And even then, since it's all text, it's very easy to bind a complex workflow to a single green mouse target called "build" or something.
Again, not calling you out. My point is that I think that having to use the cli agents isn't that much of a reason for people to get into the command line, command line is.
Not fully disagreeing, just think it's not that big of an impulse.
[OP] jmmv | 7 hours ago
I'd love to be able to say the same thing, but when people have seen me using or talking about CLI tools, they've usually smirked. That's why it bothers me that they now seem to be wanting to use these tools (while I still sense their smirk).
And no, based on what I see in my environment, the push for some CLI tools is entirely about agents. People around me are now forced to interact with Claude Code and want to run multiple instances of it in parallel. And they get lost because the previous heavy IDE tools they were given don't "scale" to these workflows.
rpaulo | 3 hours ago
My problem with Doom Emacs is that a
doom upgrademay spell … doom. I wish they had stable releases.[OP] jmmv | 22 minutes ago
Right... that's why, as I mentioned in another comment, I never run
doom upgrade. I just nuke~/.emacs.d/and reinstall from scratch. I have been doing this a few times per month for a long time now and never ran into issues.fazalmajid | a day ago
I've been using it for 33 years, and it does everything I need in an editor or IDE.
aag | 19 hours ago
42 years, and I'm still customizing and learning Emacs. The only thing I can't figure out how to do in GNU Emacs is WYSIWYG HTML editing, so I'm working on an Emacs subset specifically for that purpose.
zmitchell | a day ago
Count me in as someone that just started learning it!
I tried out Doom Emacs a few years ago and bounced off because the latency was noticeable enough to be annoying. I'm not sure if native compilation has made that a thing of the past, I'm in vanilla Emacs without anything configured yet so I don't think I would notice. I'm also running 30.2 from Nixpkgs, which I think enables native compilation by default.
I mostly don't care that I can do things like write email in Emacs. I just want an editor that I can mold, and that is capable if/when I want to learn a lisp (Janet, probably). Helix doesn't have plugins (yet), so I'm pretty much out of luck on the lisp front there. I also like the "everything is text" philosophy, but we'll see how I get on with that.
There's a few things that make learning it in 2026 kind of daunting:
$THING. I've picked up Mastering Emacs for a guided learning path.hjklkeys are in the same location on all of my keyboards. TheCtrl, etc keys are not.stmonty | a day ago
If you're coming from Helix, maybe check out meow. It provides functionality out of the box that is like Kakoune and Helix (though I haven't personally used either so this is just from what I have heard) and tries to stay more out of your way.
I think the evil package which you have been recommended has the problem of taking over too many key-bindings and not playing nice with a lot of external packages (therefore needing lots of "adapter" packages). I find that meow for me has been very hands-off since I configured it once.
FPGAhacker | 21 hours ago
So it turns out that things that make you feel like your brain is melting are actually quite good for maintaining cognitive capacity as you get older. The old “use it or lose it” aphorism applies.
We have to pick and choose when we spend our cycles so to speak, but our brain isn’t a bank, and not spending cycles at all leads to atrophy.
So don’t completely shun the brain melt. It’s a sign you are exercising your brain in a novel way and building more neuronal connections.
rprospero | a day ago
If you're having issues with the keybindings and you're a bit more familiar with vim, it might be worth having a look at evil. You'll probably hear admonitions that evil is for Vim refugees who don't want to learn the true Gospel of Emacs, but the True Gospel of Emacs® is that you use it the way that works best for you.
As a bit more to back up that point, I've been using Emacs since 1998 and was never a Vim aficionado. Around 2011, I started having some minor RSI issues and I decided to try different packages to help with that. I spent a few years heavily engaged in god mode, but it still felt clumsy. Then, just to prove that it wouldn't work, I tried evil, having never used vim before in my life. In a week, I was just as proficient with evil as I was with god mode. In a month, I was faster with evil than I had ever been with even the official Emacs bindings.
Now, coming back around to the True Gospel of Emacs®, that doesn't mean that there's anything wrong with using the default bindings. My wrists don't work, so my experience with them will not exactly match your own. You might also find joy in boon or meow. However, if evil does work for you, then don't feel one drop of guilt, because, while Emacs will change you, that will pale in comparison to the ways that Emacs will change for you.
zladuric | 15 hours ago
I've been looking at split keyboards for a while now. Recently I started thinking about a custom one. What do people use in this area that is vim friendly?
kqr | 14 hours ago
I think starting out on vanilla Emacs is the right call, to learn where its rough edges are and where it ends. But when you feel comfortable, I can warmly recommand installing Evil as one of the first things you try from the package ecosystem. It gets you sane bindings in most places.
gcupc | 8 hours ago
If you want a more Helix style experience in Emacs, take a good look at Meow. It's kind of a lot to take in, but it should be pretty straightforward to get things the way you want within that framework.
kablamooo | a day ago
It really depends on how you configure Doom. It’s also been improving overtime in that regard. The best is obviously rolling your own but it is a lot of work and projects like doom do ease the ingress of new users
[OP] jmmv | a day ago
That's what I've liked about Doom Emacs though!
I used to know the native Emacs key bindings well-enough but never found them very natural, and they were not particularly discoverable. The way Doom Emacs works, with SPC as the prefix for almost all operations and with transient menus explaining possible completions when you pause, is pretty great. I've been able to discover functionality I didn't know existed, and these don't interfere at all with the Vim modal modes. So I'm finding the mixture of Vim modes for text editing + SPC combinations for Emacs operations to be a good balance.
One plus for Emacs-native keybindings, however, is that all the basic text-manipulation ones are shared with readline and even macOS. (Mind you, I found VSCode on macOS pretty nice because macOS propagated its native Emacs-like keybindings for text management and these didn't collide with the standard clipboard management ones. When I moved to Windows and now Linux, I could just not stand VSCode without the Vim plugin.)
koala | 15 hours ago
This is why in my public Emacs documentation I recommend only two changes to the Emacs default configuration to start with, and one of them is
which-key-mode, which is in base Emacs and I suspect it's what Doom uses.Given that many Emacs shortcuts are clustered around stuff like
C-xandC-c,which-key-modeenables much of this discoverability you mention.The other change I recommend is
fido-vertical-mode, which means thatM-xpops a substring search of commands instead of a bare command line interface. The UI also shows the shortcuts of matched commands, which also helps with discoverability.(Unfortunately, there's a lot of Emacs-specific terminology [like yanking, etc.] which hampers discoverability. I wish Emacs standardized some kind of aliasing to more common terms.)
classichasclass | 23 hours ago
I've used vi for decades, mostly because I can't remember how to exit.
itamarst | 23 hours ago
At some point I expect to show my daughter emacs, and when she responds in confusion and horror explain that "The tradition of all dead generations weighs like a nightmare on the brains of the living." I'm sure it'll go over well.
jfloren | 6 hours ago
"Well you see, at MIT in the early 70s..."
Show her GNU Info next, barely changed from the ITS days.
gspr | a day ago
I'm a weirdo who uses Emacs for development, for writing, and for email, and have done so for about 15 years – yet I've never found the time or headspace to learn elisp. I don't actually know what I'm doing when I'm messing with my config file. That this is somehow still my most productive environment says something about how amazing that editor is :-)
Actually reading Mastering Emacs has been on my todo list for longer than I want to admit.
Boojum | 13 hours ago
Beyond writing your config file, knowing how to write a little elisp can be amazing with regexp search-and-replace. In a replacement, you can write
\,and then an elisp expression. So for example:[0-9]+ → \,(1+ \#0)[0-9]+\.[0-9]* → \,(format "%.2f" \#0)foo \([a-z]+\) → foo \,(capitalize \1))Within the elisp expression in the replacement, \1 etc. evaluate to the numbered capture group, interpreted as a string, while #1 etc. evaluates to the the capture group interpreted as a number.
You can do some crazy stuff, especially if you define a small function for more complex processing and then call it from the replacement expression like this. It can let you do search and replace with some smarts.
It's one of those cool Emacs tricks that I've never seen anywhere else, but comes in quite handy every now and then.
k749gtnc9l3w | 12 hours ago
Of course Vim supports that, too. Of course I never remember to actually use it.
jperras | 23 hours ago
Honestly, I'm mostly in the same boat. I know a little bit of elisp via osmosis from updating/editing my configuration, but it's actually a bit embarrassing how little of the language I know.
sammyo | 23 hours ago
M-x high-five
This is me, very few packages and orig key bindings. (and there isn't actually a high-five func, maybe I'll finally dig into elisp:)
mond | a day ago
helix gang rise up
(plugins any year now)
[OP] jmmv | 5 hours ago
I've at some point tried to use Helix because it sounds great (native Rust, simple configuration, no Elisp that I haven't grasped yet; I'm sold!). But then I get such an uncanny valley feeling due to the Kakoune-style shortcuts... and I still use Vim a lot for quick edits, so I think I just cannot make that switch...
dasnacl | a day ago
I have flip-flopped between doom and (n)vim back and forth, but have "recently" mostly settled with neovim. Key issues for me while using emacs - and it is somehow hilarious to say - is pain to maintain. Upgrading doom frequently left me with only the nuclear option of completely reinstalling due to out-of-sync packages. Sure, I could've fixed it less "noob"y, but at some point you just stop caring and want your stuff to work. Can't afford configuration breakage and heavy editor-dependency when there is work to do. Though, I do miss org-mode and just overall navigation in emacs.
Whenever I tried any of the more "modern" solutions, say VSCode, CLion or whatever, I have the same issue - and more! Now, I have to click around awkwardly instead of plain keyboard navigation, because they don't properly implement accessibility features. "vim" motions is a crippled version of the true thing.
Why neovim nowadays? It just works. Honestly, could say the same about emacs nowadays if I'd just spent 2 mins asking a coding agent to fix my config... oh well (:
[OP] jmmv | a day ago
I've tried doom's "update" feature sometimes and always had trouble.
Nowadays I just
rm -rf ~/.emacs.d/and set up doom from scratch (I keep~/.doom.d/under version control) every time I feel like upgrading or have to upgrade because Emacs gets upgraded. Never had issues with this flow.varjag | 4 hours ago
My peeve with Doom/Spacemacs and other quirky chungus emacsen is exactly their disrespect to original keybindings. That makes communicating editor functionality to people using them somewhat frustrating.
facundoolano | a day ago
Yes, turning 10 years as an Emacs user
duncan_bayne | 22 hours ago
For decades now. No plans to change.
untrusem | 17 hours ago
All day, everyday :D
meain | 17 hours ago
I have been using Emacs for about a decade. The best part about Emacs is its malleability. Using something like Doom kinda take a hit on it, but still way better than VSCode or other editors. I am Vim to Emacs convert from the pre Neovim era and have been happy with Emacs since. In addition, now that we can ask LLMs can work with Emacs, I can ask an AI to fix any minor inconveniences that I have in my Editor and we are good.
Let me give you a small example. I wanted to update the order in which files show up in the file picker. Here is a small set of rules I wanted to apply:
I could easily do this within Emacs with a couple of lines of elisp to hook into the file sorting logic and modify it in the running Emacs instance. Even better, I could explain this much to an LLM, give it
emacsclientto evaluate elisp and I have it in 5minutes without even looking at the code. If you had to do the same within VSCode, I'm assuming you have to develop a separate plugin, but then now you are likely also responsible for creating your own popup menu. And to test it, you now have to load another VSCode instance with the plugin loaded. I hope you get my point.josef | 17 hours ago
A lot of the work I do would be almost impossible without Emacs. The custom modes I’ve written for editing my peculiar documents would be just a pain in any other editor.
cryptix | a day ago
Yup! I switched to it like about two years ago because I didn’t like vims rendering and was f**ed up with electron/vscode likes.
I got hooked on avy and some jumping plugins but what really made me stick and still is my main driver for code changes, is magit.
kablamooo | a day ago
Yes, me. But I’m probably not that common. I deal with a client at work that their entire business involves leveraging very large csv files and apparently nobody there seems to know how to open or review data in a 1gb file. They don’t even know what the head command is to give me the headers of a csv.
alemi | a day ago
Just switched to
-nwafter many years of X/GUI. Using the Pgtk version only for doing presentations.ayushnix | 14 hours ago
I've been considering switching back to Emacs after using (neo)vim for almost a decade but I'm not convinced that Emacs has/will have a strong anti-LLM policy for development and contributions. It seems like the only thing holding back the GNU community from using LLMs is FSF's verdict about the copyright situation of LLM generated code and I view the impact of LLMs on the environment and their relationship with copyright as the two weakest arguments one can take against LLMs.
I don't want to invest hundreds or thousands of hours on my text editor ((neo)vim) only to discover that its developers are using LLMs.
pm | 9 hours ago
Interesting post.
One thing that doesn't get talked about enough if the friction between TUI editors and the host operative system clipboard. TUI editors predate desktop environment clipboards and because of that they have their own.
This is the main reason I never committed to TUI editors even though I make heavy usage of terminal emulators.
Other than that, I think VSCode does borrow a lot of ideas from emacs. It's philosophy has much in common with emacs'. Extendable, centered around text buffers rather than UI widgets, comes with a built in terminal that can be open both full screen and in a split buffer, and so on.
adam_d_ruppe | 7 hours ago
There's two counters to this: 1) idk about emacs, but vim actually can integrate with the host OS, though the key sequence is a bit awkward: "+ (or "* for X's PRIMARY). This works pretty ok on Windows, and on X it opens a new connection to the DISPLAY which is... ok, but has an annoying element in that I'm frequently migrating open terminal sessions between systems and this connection doesn't migrate with it. On my own setup, I modified vim to instead send a "request clipboard" escape sequence to the terminal, which is passed down and back up the chain through the OS, but it is a bit janky, vim did not want to do this and it is a hacky key rebind instead of a complete integration.
But if you mostly keep your sessions on the originating display, the built in thing works ok once you get used to the key sequence.
or 2) you can use the terminal emulator's integration. Shift+select to copy and middle click to paste. This is what I do most often and it works fine, with bracketed paste vim handles it fairly well. Selection can be janky since it is what is displayed in the emulator instead of the original buffer but still usually good enough.
pm | 2 hours ago
It's not about being impossible. It obviously is possible. It's the horrible friction which vim/emacs user tend to underestimate but which 99%+ of the users would never bother to check.
I can use the arrow keys. Home and end keys, insert, delete, backspace, Ctrl+arrow, Ctrl+end, Ctrl+arrow, shift+arrow, shift+end, Ctrl+shift+end/home/arrow, Ctrl+a, Ctrl+x/c/v and so on, in any text area of any application and it all works reliability and seamlessly. Negating access to so brutally practical functionality is huge deal breaker.
Neackbeard grown solutions to mitigate such a big deal won't cut it. No offense. Sure, some guy has written this and that integration that is just a matter of installing this and that plugins and had edit 5 lines of elisp or vimscript that can be in a file in one of these five locations... But that that point you already lost the interest of maybe a couple extra nines of your potential market share which was already bellow 1%.
The momentum gravity pull of the desktop environment is just too strong.
koala | 9 hours ago
I use the xclip package in terminal Emacs and it works well enough for me.