I kinda wish I hadn’t learned Vim — just so I could learn a more modern modal editor, Kakoune. Relearning the commands to be pretty much in reverse order (”word delete” instead of “delete word”) sounds like hell. Now, I did learn to type on Colemak after QWERTY.. but the Vim Muscle Memory™ seems much stronger than the QWERTY one was.
faking multiple-cursor support by coloring parts of the buffer to look like cursors and then repeating the actual cursor’s actions at those regions
Oh that’s how it’s actually implemented!! Dang, that’s pretty clever.
After using Vim pretty much daily for nearly two decades, a month or so of light Kakoune usage was enough to wean me off Vim entirely. Vim’s a big program with a lot of features, so maybe I wasn’t using the really addictive ones, but I’ve seen similar comments from other people in #kakoune, so I’m not alone.
The key-chording thing is definitely an issue, but one that can be worked around to some extent with mappings. I don’t think there are any two-modifier keystrokes I use regularly, so it takes me at least as long to remember them as it does to type them.
I was actually pretty impressed with how string-quoting works in Kakoune. Although normal quoting works as you’d expect, the nestable quoting syntax %{} is, well, nestable, which means it almost never needs escaping and so deeply-nested string quoting is just about as natural as {} blocks in C.
That said, Kakoune’s “scripting” is definitely unusual… it’s very much in the vein of basic Unix and Plan9 tools where it’s blissfully easy to hack together a solution that solves a specific problem, but trying to generalise that solution is nearly impossible. I do find that frustrating, but would I be more productive with an editor scripted in.. say, Haskell? Probably not.
I can navigate by paragraph with [p and ]p. I don’t think I’ve ever deliberately used , in Vim or Kakoune, but for any kind of repetition I generally hold down ‘X’ to select a bunch of lines and the s command to create a selection for each thing I want to change. If I hit wi, that starts inserting before the word I just moved over; wa starts inserting after the word I just moved over (including the trailing whitespace). If you want to insert after the word but before the whitespace then yes, you’d need w;i… or just ea. I remember when I started using Kakoune, moving the selection around to the place I wanted it to be felt a bit like a sliding block puzzle, or a game of Snake, where I had to think about where my tail was going to end up as well as getting my head in the right place. I got used to it pretty quickly, though.
In Kakoune as well as in Vim, I tend to open an editor session in the root directory of my project and open files with relative paths from there (unless I can get there with gf, or I have a handy “find” command that autocompletes all the filenames in my project so I can just type a few letters of the file I want to open). I guess I can see the appeal of having a current directory per buffer, but I guess I’ve learned to think of my projects’s structure from a top-down perspective rather than bottom up.
At the end of the day, though, Kakoune’s got multiple cursors, and I don’t think I’ll ever be able to give that up.
Why would you want to switch from modal vim to Kakoune? After browsing the top features of Kakoune, I didn’t see anything there that’s either not supported natively in vim, or couldn’t be enabled by a plugin or two.. So I’m genuinely curious what the motivation is behind the desire to switch.
Thanks, wow, that is an incredible concept. I guess I should have spent more time clicking around. Seems like they’d want to call that out on the front page!
I’m a long-term Emacs user, but about five or so years ago I was starting to feel a bit of strain on my hands and forearms from all the typing I was doing. While Emacs usage surely wasn’t the only culprit, I went ahead and switched to evil-mode to give it a try, and I’ve never looked back–I personally feel like the configurability and programmability of Emacs is ideal, while the modal editing of Vim is ideal, so having them together in one package seems like the best of both worlds. It seems to have helped alleviate the strain as well.
Anyways, this is all just to say, I highly recommend giving it a shot and seeing if you like it (EDIT: but keep in mind there is a learning curve…it was slightly less painful for me since I’ve been using Vim off-and-on for sysadmin-related tasks for years, YMMV).
(Note that there is also god-mode which sounds interesting, but which I haven’t tried.)
Another evil-mode convert here. Switched a couple months ago. The most surprising thing to me was how many libraries are out there to make evil so much more attractive: evil-args (each argument in a C-style function call is a text object), evil-surround (parens are a text object), evil-collection (hodgepodge), evil-goggles (animate region before deleting or yanking it), evil-indent-plus (all text at the same indent level are a text object), evil-escape (jk/kj). The idea of having a “text object,” which gently composes with all the verbs Vim/evil gives you, just opens up so many new opportunities for library authors.
I switched to Visual Studio Code with Neovim backend yesterday. Neovim provides all the Ext functionality so you can :s/foo/bar to your heart’s content. It’s finally Good Enough to operate as a Vim without having to spend months tuning your .vimrc. I have been using Vim for 5+ years and wrote all my Go code in it.
I think this is what the future of Vim actually is for the majority of people: Neovim providing a backend for their preferred IDE. Interacting in a terminal is incredibly antiquated, even if it’s the sort of thing you are super used to. You can spend your time actually understanding and learning Vim, not trying to make Vim do what you think is reasonable/behaves like your previous editor of choice.
Despite being somewhat of a diehard vim fan, 99% of my ‘vim’ usage these days is via emulators - either in VS, VSCode or Firefox.
For me the true value of vim is modal editing (and the associated muscle memory); the plugin ecosystem etc is fine (and at one point I spent a lot of time honing my plugin config) but there’s very little I miss.
My experience is the same. I don’t even have gVIm installed on my workstation anymore, but I love love working with the vim extensions in VS, Code, and Firefox.
Maybe some day an interface to neovim will appear for Emacs, that would be a nice thing to happen. Perhaps I could start writing it, if I have a chance to learn elisp. Emacs as the extensible front end, with a proper modal backend. In fact the front end could be something better than Emacs, an scheme implementation would be amazing, in order to preserve separation of interests and provide users with a lightweight but infinitely extensible editing environment. If someone with adecuate skills for this (I don’t have them at the moment, so I will have to invest some time learning) is willing to start a with me such project, I would be more than honored to do so, if no interest is shown, eventually I would do it on my own.
Thanks for the recommendation, but I’m not interested in bringing the web to the desktop with the Electron framework, as exciting as it may be for many programmers I think it is still a bad idea. Personally, I think we don’t need tenths of MB in programs’ binaries in order to do text editing, and Javascript isn’t a coherent nor a well defined language to justify its expansion on servers and home computers, I think there are better alternatives to this. Nevertheless, if you like it and it solves your problems, then that’s all that matters in the end.
I don’t actually use it - I use plain neovim in my terminal. I agree with you on the criticisms of electron - it’s just the only program of its kind that I’ve found.
For those who aren’t aware of it, I’d like to put in a recommendation for Spacemacs. For me, as a 30-year Emacs user and 8-year Vim user, it’s the best of both worlds. The modal editing language of vim, the discoverable sensible space menu system, and all the power of Emacs (e.g., Magit).
There is also a lightweight alternative - “Doom Emacs”, almost all of the benefits of Spacemacs but fast as a cacodaemon ;-) Feels really snappy and starts in less than a second.
This is a pretty good intro to vim. In addition to the vim tutorial the author mentions, vim golf[0] is a really fun way to learn new tricks and practice.
I think I’m the only vim fan who doesn’t like vim golf. I think it teaches the wrong lessons. Vim isn’t about saving keystrokes, that’s just a metric by which we measure saving time and mental overhead. Sure, df will be fewer characters than d/, but then you have to count letters to make sure you pick the right one. That’s gonna slow you down a lot.
I also think that it contributes to the meme that we should be using as pristine configurations as possible. But you get incredible power out of maps. Having s map to "_d is way more useful than the default command.
Sure, not all solutions to vim golf challenges are practical ‘in real life’, but I sure have learned a lot of tricks that are practical ‘in real life’ by looking at how others have solved some of the challenges I’ve attempted..
This is actually one of the nicest, cleanest and objective write ups on adopting vim that I’ve ever read.
I kinda wish I hadn’t learned Vim — just so I could learn a more modern modal editor, Kakoune. Relearning the commands to be pretty much in reverse order (”word delete” instead of “delete word”) sounds like hell. Now, I did learn to type on Colemak after QWERTY.. but the Vim Muscle Memory™ seems much stronger than the QWERTY one was.
Oh that’s how it’s actually implemented!! Dang, that’s pretty clever.
After using Vim pretty much daily for nearly two decades, a month or so of light Kakoune usage was enough to wean me off Vim entirely. Vim’s a big program with a lot of features, so maybe I wasn’t using the really addictive ones, but I’ve seen similar comments from other people in #kakoune, so I’m not alone.
Here are the concrete issues I ran into: https://lobste.rs/s/v17gol/switching_sublime_text_from_vim_2017#c_7dbqc1
The key-chording thing is definitely an issue, but one that can be worked around to some extent with mappings. I don’t think there are any two-modifier keystrokes I use regularly, so it takes me at least as long to remember them as it does to type them.
I was actually pretty impressed with how string-quoting works in Kakoune. Although normal quoting works as you’d expect, the nestable quoting syntax
%{}is, well, nestable, which means it almost never needs escaping and so deeply-nested string quoting is just about as natural as{}blocks in C.That said, Kakoune’s “scripting” is definitely unusual… it’s very much in the vein of basic Unix and Plan9 tools where it’s blissfully easy to hack together a solution that solves a specific problem, but trying to generalise that solution is nearly impossible. I do find that frustrating, but would I be more productive with an editor scripted in.. say, Haskell? Probably not.
I can navigate by paragraph with
[pand]p. I don’t think I’ve ever deliberately used,in Vim or Kakoune, but for any kind of repetition I generally hold down ‘X’ to select a bunch of lines and thescommand to create a selection for each thing I want to change. If I hitwi, that starts inserting before the word I just moved over;wastarts inserting after the word I just moved over (including the trailing whitespace). If you want to insert after the word but before the whitespace then yes, you’d needw;i… or justea. I remember when I started using Kakoune, moving the selection around to the place I wanted it to be felt a bit like a sliding block puzzle, or a game of Snake, where I had to think about where my tail was going to end up as well as getting my head in the right place. I got used to it pretty quickly, though.In Kakoune as well as in Vim, I tend to open an editor session in the root directory of my project and open files with relative paths from there (unless I can get there with
gf, or I have a handy “find” command that autocompletes all the filenames in my project so I can just type a few letters of the file I want to open). I guess I can see the appeal of having a current directory per buffer, but I guess I’ve learned to think of my projects’s structure from a top-down perspective rather than bottom up.At the end of the day, though, Kakoune’s got multiple cursors, and I don’t think I’ll ever be able to give that up.
Why would you want to switch from modal vim to Kakoune? After browsing the top features of Kakoune, I didn’t see anything there that’s either not supported natively in vim, or couldn’t be enabled by a plugin or two.. So I’m genuinely curious what the motivation is behind the desire to switch.
It’s not about features, it’s about this:
https://kakoune.org/why-kakoune/why-kakoune.html#_improving_on_the_editing_model
Thanks, wow, that is an incredible concept. I guess I should have spent more time clicking around. Seems like they’d want to call that out on the front page!
“Faster as in less keystrokes” is what’s on the front page. Yeah I guess they could’ve linked that text to the why page..
Sure, but it literally does not describe wtf that means. I had assumed they were just referring to macro support…
I am considering switching to evil; I’ll never surrender Emacs, but I can see the appeal of modal editing.
I’m a long-term Emacs user, but about five or so years ago I was starting to feel a bit of strain on my hands and forearms from all the typing I was doing. While Emacs usage surely wasn’t the only culprit, I went ahead and switched to evil-mode to give it a try, and I’ve never looked back–I personally feel like the configurability and programmability of Emacs is ideal, while the modal editing of Vim is ideal, so having them together in one package seems like the best of both worlds. It seems to have helped alleviate the strain as well.
Anyways, this is all just to say, I highly recommend giving it a shot and seeing if you like it (EDIT: but keep in mind there is a learning curve…it was slightly less painful for me since I’ve been using Vim off-and-on for sysadmin-related tasks for years, YMMV).
(Note that there is also god-mode which sounds interesting, but which I haven’t tried.)
Another evil-mode convert here. Switched a couple months ago. The most surprising thing to me was how many libraries are out there to make evil so much more attractive: evil-args (each argument in a C-style function call is a text object), evil-surround (parens are a text object), evil-collection (hodgepodge), evil-goggles (animate region before deleting or yanking it), evil-indent-plus (all text at the same indent level are a text object), evil-escape (jk/kj). The idea of having a “text object,” which gently composes with all the verbs Vim/evil gives you, just opens up so many new opportunities for library authors.
I switched to Visual Studio Code with Neovim backend yesterday. Neovim provides all the Ext functionality so you can
:s/foo/barto your heart’s content. It’s finally Good Enough to operate as a Vim without having to spend months tuning your.vimrc. I have been using Vim for 5+ years and wrote all my Go code in it.I think this is what the future of Vim actually is for the majority of people: Neovim providing a backend for their preferred IDE. Interacting in a terminal is incredibly antiquated, even if it’s the sort of thing you are super used to. You can spend your time actually understanding and learning Vim, not trying to make Vim do what you think is reasonable/behaves like your previous editor of choice.
Despite being somewhat of a diehard vim fan, 99% of my ‘vim’ usage these days is via emulators - either in VS, VSCode or Firefox.
For me the true value of vim is modal editing (and the associated muscle memory); the plugin ecosystem etc is fine (and at one point I spent a lot of time honing my plugin config) but there’s very little I miss.
My experience is the same. I don’t even have gVIm installed on my workstation anymore, but I love love working with the vim extensions in VS, Code, and Firefox.
Maybe some day an interface to neovim will appear for Emacs, that would be a nice thing to happen. Perhaps I could start writing it, if I have a chance to learn elisp. Emacs as the extensible front end, with a proper modal backend. In fact the front end could be something better than Emacs, an scheme implementation would be amazing, in order to preserve separation of interests and provide users with a lightweight but infinitely extensible editing environment. If someone with adecuate skills for this (I don’t have them at the moment, so I will have to invest some time learning) is willing to start a with me such project, I would be more than honored to do so, if no interest is shown, eventually I would do it on my own.
Check out Oni!
Thanks for the recommendation, but I’m not interested in bringing the web to the desktop with the Electron framework, as exciting as it may be for many programmers I think it is still a bad idea. Personally, I think we don’t need tenths of MB in programs’ binaries in order to do text editing, and Javascript isn’t a coherent nor a well defined language to justify its expansion on servers and home computers, I think there are better alternatives to this. Nevertheless, if you like it and it solves your problems, then that’s all that matters in the end.
I don’t actually use it - I use plain neovim in my terminal. I agree with you on the criticisms of electron - it’s just the only program of its kind that I’ve found.
Sorry If I assumed something incorrect. Some of the ideas in Oni seem interesting, and would be a worthwhile effort to have a look at the source code.
Little off-topic, but what do you use to do that integration?
The VSCode Vim plugin will do it out of the box, just check “Enable NeoVim”
Great article!
One nit: No mention of neovim at all!
For those who aren’t aware of it, I’d like to put in a recommendation for Spacemacs. For me, as a 30-year Emacs user and 8-year Vim user, it’s the best of both worlds. The modal editing language of vim, the discoverable sensible space menu system, and all the power of Emacs (e.g., Magit).
There is also a lightweight alternative - “Doom Emacs”, almost all of the benefits of Spacemacs but fast as a cacodaemon ;-) Feels really snappy and starts in less than a second.
Thanks for the tip! Yeah, Spacemacs pretty much requires you to use an Emacs daemon. Very slow startup.
Reading the article made appreciate vim even more (though I switched to Emacs recently since my interest now gravitates to Lisp).
This is a pretty good intro to vim. In addition to the vim tutorial the author mentions, vim golf[0] is a really fun way to learn new tricks and practice.
There is also this adventure game.
https://vim-adventures.com
That seems like it would be fun, but unfortunately it’s a pay-to-play game after a certain point (level 2? if memory serves..)
I think I’m the only vim fan who doesn’t like vim golf. I think it teaches the wrong lessons. Vim isn’t about saving keystrokes, that’s just a metric by which we measure saving time and mental overhead. Sure,
dfwill be fewer characters thand/, but then you have to count letters to make sure you pick the right one. That’s gonna slow you down a lot.I also think that it contributes to the meme that we should be using as pristine configurations as possible. But you get incredible power out of maps. Having
smap to"_dis way more useful than the default command.Sure, not all solutions to vim golf challenges are practical ‘in real life’, but I sure have learned a lot of tricks that are practical ‘in real life’ by looking at how others have solved some of the challenges I’ve attempted..