Richard stallman himself got repetitive strain injury from emacs. So many people have. They tell you to remap the key to caps lock they tell you to use your palm instead of your finger they tell you to get a weird keyboard but at the end of the day it was just poorly designed.
Vim is only slightly slower but so much easier on my hands. Yes, I could get emacs evil or spacemacs or whatever but bolting on modality to an editor that was never meant for it, especially when all the docs basically ignore their existence, is not something I'm interested in. Native vim is just better.
But I do miss that you can configure emacs using lisp.
There is hope, though. I've heard there is a plug-in for neovim that allows you to write configuration files using common lisp.
> In the mid 90s I had bad hand pain, so bad that most of the day I could only type with one finger. The FSF hired typists for me part of the day, and part of the day I tolerated the pain. After a few years I found out that this was due to the hard keys of my keyboard. I switched to a keyboard with lighter key pressure and the problem mostly went away.
> My problem was not carpal tunnel syndrome: I avoid that by keeping my wrists pretty straight as I type. There are several kinds of hand injuries that can be caused by repetitive stress; don't assume you have the one you heard of.
Mine was more ulnar tunnel (emacs pinky) than carpel. I too had the problem of the hard keys. From what I can tell my problem was that my muscles grew so tight that there was no space for my nerves, causing owner tunnel numbness. Neurologist tested my nerves and found no damage, and the massage therapist I later visited told me that this could happen. It also explains why rock climber's stretches helped me make the problem go away. But to this day it comes right back the minute I turn on emacs.
I really want a basically traditional keyboard, except with a thinner space key that permits two more modifier keys under each thumb. The anatomy of the hand is meant for the thumb to work in opposition with the other four fingers.
Sadly the ErgoDox doesn't fit my hands so it's uncomfortable to use the thumb clusters. The Kinesis does if I place it very low, but I'd like to retain the rest of my muscle memory for key location.
> but bolting on modality to an editor that was never meant for it
Frankly, I don't even know what you're talking about. Modality is all over Emacs. It was there even before Evil. Some extensions even use modality completely differently - not like in Vim.
As an avid, hard-die Vimmer, I tend to agree when people say "there's no such thing as Vim-emulation", it's either Vim/Neovim or something half-baked.
But Emacs is an utterly different beast here. Emacs can and does vim better than Vim and Neovim. Anyone who argues differently perhaps has never gotten deep enough in either of those muds.
It's not absurd. It very often does "vim" better, I'm using "vim" here as a verb, apply whatever meaning your heart desires. Even when it comes to some practical text manipulation like I once demonstrated here: https://www.youtube.com/watch?v=UieaT354GkU - I needed to replace every single occurrence of UUID in the file, generating a new one in the stead.
I think that emacs with evil mode is a superior vi-like editor than either NeoVim or Bram's Vim. I haven't found the docs to be an issue, I don't need the emacs docs to tell me how evil works because I already had years of experience with Vim before switching to evil+emacs.
Arguing that Vim or Neovim run faster than Emacs is like saying that your single-engine sport aircraft moves faster than my best aircraft carrier. An average Emacs user installs and loads a few hundred packages, ranging from Org-mode and version control extensions to PDF tools, and natural language assistants. I bet Vim wouldn't be "faster" if you feed it up with even half of that number of plugins.
Vim and Emacs have different use-cases, philosophies and mechanics. Each has its own pros and cons. There's no point in debating if one has better speed, aesthetics or popularity. I suggest we stop this nonsensical debate of Vim vs. Emacs and instead focus on their strength.
What people very often miss is that both Vim and Emacs are absolutely free. Free to use, free to copy, free to change. And that freedom is worth protecting and worth fighting for. Because no matter how MSFT, JetBrains, et al. paint it - VSCode and IntelliJ are not free products. And not just the money at stake here - the entire ideology and the idea of being a hacker with control over computational power and the tools is something worth protecting. I (just like many others) am so fed up with proprietary services and corporations taking your data hostage. Tired of being locked in and losing control over my data; tired of the status quo, of that infamous: "people don't know what they want..."
I chose Vim & Emacs not because they are technologically superior to VSCode or IntelliJ (even though they are), but because I've seen the other side. I've used Jetbrains' products for many years. I loved them, blindly. Do you know what grants you a huge amount of satisfaction? Not when you see that bug ticket you filed in 2008 gets finally fixed in IntelliJ, fourteen years later (by that time you're already forced to learn how to avoid the workflow leading to that bug).
Satisfaction is what you feel when you learn Emacs to the point that even though you know there's a bug, you've accumulated enough knowledge to sit down and figure out a workaround for it, writing fifty lines of Lisp. That's freedom. That's being a programmer. Choosing to pay for a proprietary product and ecosystem (because it has emojis and pizzzaz) is like jumping into a slow melting pot; willingly checking-in into a mental prison.
> Arguing that Vim or Neovim run faster than Emacs is like saying that your single-engine sport aircraft moves faster than my best aircraft carrier.
Vim vs. Emacs debates these days remind me of a story I read about an F-16 pilot and an A-10 Warthog pilot sitting in a bar, debating the merits of their respective planes. At one point the F-16 pilot said something like "Come on, you have to admit that an F-16 with AIM-9 Sidewinders on its pylons is pretty badass!"
The Warthog pilot just smiled. "Do you know what the pylons on my 'Hog are meant to carry?" he said. "F-16s."
I've long considered Emacs to be the Warthog of editors: big, ugly, a little outdated, but absolutely your best friend when it comes to certain big ugly jobs (and nothing else comes close). These days it comes with a pretty decent implementation of much of Vim, so it really is like a Warthog carrying a pair of F-16s. That said, it also has in common with the Warthog that its number is coming up and it is probably soon to be retired permanently because the landscape has evolved out from underneath it.
> What people very often miss is that both Vim and Emacs are absolutely free. Free to use, free to copy, free to change. And that freedom is worth protecting and worth fighting for. Because no matter how MSFT, JetBrains, et al. paint it - VSCode and IntelliJ are not free products. And not just the money at stake here - the entire ideology and the idea of being a hacker with control over computational power and the tools is something worth protecting. I (just like many others) am so fed up with proprietary services and corporations taking your data hostage. Tired of being locked in and losing control over my data; tired of the status quo, of that infamous: "people don't know what they want..."
Most developers use Visual Studio Code. IntelliJ is still largely considered a must for development in Java-family languages. Microsoft and JetBrains are doing something right. It may be the case that people really don't know what they want. Whatever the case, if you work as a professional and do not use the tools that maximize your productivity, you are leaving money on the table.
> That said, it also has in common with the Warthog that its number is coming up and it is probably soon to be retired permanently because the landscape has evolved out from underneath it.
Do you think so?
Unlike the Warthog, Emacs has also been evolving. Doesn’t LSP close a large part of the gap with IDEs?
Emacs still has no parallel multithreading, very poor async support, lots of global state everywhere, and you still have to contend with Emacs Lisp. So no, I say it hasn't evolved to keep up with the state of the art.
Your URL is about how fast the software is at responding to the user's keystrokes. In contrast, the person you are replying to is writing about the effect of key binding on how quickly a user can get common tasks done.
It's weird I used vim for 5 years and started getting really sore hands, so in early 2019 I switched from QWERTY to Dvorak layout, and at the same time decided to try out Emacs. Nowadays my hands are in far better shape.
I sometimes try using Evil, but every time I have to stop because my fingers become sore. I guess it's because when using modal editing I slam the keys down. That's because mistypes can be disastrous when compared to Emacs where mistypes just end up as characters in the active buffer.
This is actually true, but not an issue anymore. Control was near the space bar in the Symbolics keyboard, now it's in a much more comfortable position where it can and should be pressed with the left hand's palm, which is important even if you don't use Emacs. Vi uses control too.
One way to avoid strain on Emacs is to move your hand over an inch or so for certain keys. I tend to use M-x ${function-name} for new modes and commands that I learn, so this is not a big deal to me.
Speed is nice, but it is not the main goal. Getting things done is (no pun intended).
Vim is only slightly slower but so much easier on my hands. Yes, I could get emacs evil or spacemacs or whatever but bolting on modality to an editor that was never meant for it, especially when all the docs basically ignore their existence, is not something I'm interested in. Native vim is just better.
But I do miss that you can configure emacs using lisp.
There is hope, though. I've heard there is a plug-in for neovim that allows you to write configuration files using common lisp.