I've been using Vim for years, but if there was one thing I could change, it would be the verb-noun order. The Kakoune[1] editor behaves mostly like Vim, but where Vim has `dw` as "delete word", Kakoune has it backwards: `wd`.
It might sound minor, but by placing the range first, Kakoune can give a preview of what will be changed. The longer or more complicated the command, the more this feature shines.
Strictly better as far as I know. A shame my muscle memory, and all default installations, are still stuck with Vim.
I've Vim for years been using, but if one thing I could change there was, it the verb-noun order would be. The Kakoune[1] editor mostly like Vim behaves, but where Vim `dw` as "word delete" has, Kakoune it backwards has: `wd`. It might Germanic sound, but by first the range placing, Kakoune can a preview of what changed will be give. The more the command longer is, the more the command complicated is, the more this feature shines. It strictly better as far as I know is. A shame my muscle memory, and all default installations, are still with Vim stuck.
English swaps it around as convenient, so do common computer systems - you can verb(data) or data.verb() in the more popular languages and I think it's no coincidence that the popular languages have both or the languages which have both became more popular. If a choice is a toggle, one size nobody very well it fits.
The issue is not the linguistic aspect of verb-noun, which does match English, but rather the difficulty of composing the range to act on after you've already started typing the verb. With the verb first, you're in a bit of limbo trying to specify the range. It's much nicer to get your range in order, then act on it.
The vim equivalent of that is visual mode, eg `vwd` which is exactly the same structure as you’re saying you want from kakoune.
So vim is verb-noun for simple things, but if you want, you can use visual mode if you’re doing something more complex or just want visual confirmation first.
That's exactly what I do, because I need the visual confirmation and can't really wrap my head around it otherwise.
Sometimes when I don't realize I'm in insert mode, I jump around the document and don't know what just happened. Visual cues in-between would have been nice, so I don't always feel as surprised as I do, lol.
Although I don't know if in that particular fiddly case it would have any benefit.
Not an equivalent, visual mode extends selection on move, so you can't stay in perma visual mode like you can in the Helix/Kakoune world where extending selection is different
As a vim user for many years, probably influenced by reading about kakoune, I had gotten in the habit of prefixing all my actions with v to start in the visual mode, somewhat like the kakoune-way, previewing my selections before I use them.
However, recently I've repented my errors. Having discovered that insert mode <M-Key> functions as normal mode <Key> and moving away from the visual mode whenever possible, I realised that despite the touted simplicity of the selection-action model, there is much cognitive benefit to the vim-way, in making keys function as one bigger conceptual step, combining the motion and the verb into one inseparable unit.
Compared to using visual mode, I no longer wait to look at previews then continue, but simply keep typing away, one command after next, trusting that my machine will follow, it catching up the 'buffer' of my commands at its pace. This truly helps me feel much more connected with my work at hand, 'feeling' my text, not going back to seek at what I expect already, and forgetting about the details. Getting used to performing actions in just one step, albeit a bigger one, allows me to think more effectively about how I edit my text. Conversely, to allow only the expression of 'simple' text concepts does not reduce my cognitive burden, as I would need to, and be thinking of, how to use 'simple' text motions/selections to emulate more complex ones anyway.
On another note, I've finally found myself embracing vim's window management, terminal, buffer management... I'm in awe of the way that vim has gently paved for me, all along. Beyond minimalism, as a shell/terminal multiplexer, vim is great.
I've been test driving the Helix editor (mostly because of its out-of-the-box support for a wide range of LSP servers), and it adopts the kakoune style of keybindings. Like you, my muscle memory is very strongly in the Vim camp, and is hard to change :)
My muscle memory can adapt. In terms of day-to-day use, I found it nearly impossible to deal with the behavior of the key combination "xd". "x" is "select-line" and "d" is "delete". So this should delete the current line.
But if you're on a blank line, it will delete the next line, not the current line.
If you can figure out why this is, then you are close to understanding how kakoune manages the concept of "line" and "cursor" and "selection", but for me this is an abstraction gap too far. I can't make the conceptual leap. And once you understand the line/cursor/selection model, you see that this is unfixable.
If someone wrote a way to transplant strict Kakoune keybindings into Neovim, I'd change in a heartbeat. Unfortunately I'm too immersed in the plugin system as it is.
It's interesting that the increase in Vim commits is concurrent with the fist release of NeoVim. They've certainly both been good for each other and I'm hoping this won't change with Bram's passing.
No, it wasn't, and hasn't been since the 90s (most of the gvim code was written by others back in the day, to give an example of a large body of code not written by Bram). There have been many people contributing, and some of them for years.
Yes, Bram was the BFDL and the only one committing patches, but don't confuse that with "one man show".
I love Vim, and although my usage is totally vanilla these days, I use Vim plugin for VSCode which is awesome (lack of :norm is the only downside I've found).
Although it will never be as popular as Vim, I will always see Kakoune as the evolution of Vim. It improves on so much and adds very well thought out functionality. Object-verb works very well when you adjust, and structural regular expressions make a lot of operations much less painful.
Built-in multi cursors and autocomplete without fiddling with plugins is wonderful, and the in-editor discoverability and documentation is great.
It retains Vim's spirit of minimalism but cuts out a ton of cruft without constraining itself to any kind of backwards compatibility.
I use Kakoune as my $EDITOR and VS Code with Dance for software development. I think Dance does a great job of leveraging Kakoune and VS Code's strengths. I wish there was an equivalent for Intellij as well.
> most users found frustrating having to work with ed.
True, until you need it. And you'll usually pull out ed when any other editor fails :D One example is an extremely slow ssh connection. For those who can recall, when SourceForge allowed ssh access, running vi/vim was a PITA if you wanted to edit something. But not with ed.
The second example of where ed is unmatched is scripting - it has the same "interface" for interactive editing and scripting (it uses the same commands and command sequence). Someone also mentioned (can't find source of the quote) that the same trick is helpful when you write a book because you can easily print ed command sequence readers can repeat and follow your examples, which isn't the case with any other visual editor. You can write unit tests to validate those things in case you want to ensure your book examples actually work.
As a footnote to history, Manx Aztec C shipped with a complete set of Unix-like tools for non-Unix systems. This included a partial VI clone of their own. So users of Aztec C for MS-DOS, Mac, Amiga, Atari-ST etc all got VI clones as part of the deal.
I have been a VI user my whole life as a result (I worked for Manx in the late 80's, and their flavor of VI was my first real taste of text editing).
Good historical overview of vim and its origin. I remember using vi for the first time at my university because emacs would slow down to a crawl on our unix clone system especially just before our computer science homework was due, and I was forced to switch from Emacs to vi. During that time, Amiga was my home computer, but I don't remember seeing it on Amiga. Most of my time was spent at school on a Wyse VT-220 clone terminal. Since then, I've tried Elvis, nvi, and few other clones until settling with vim much later in life when Ruby on Rails came onto scene.
Readit News
It might sound minor, but by placing the range first, Kakoune can give a preview of what will be changed. The longer or more complicated the command, the more this feature shines.
Strictly better as far as I know. A shame my muscle memory, and all default installations, are still stuck with Vim.
[1] https://kakoune.org/
English swaps it around as convenient, so do common computer systems - you can verb(data) or data.verb() in the more popular languages and I think it's no coincidence that the popular languages have both or the languages which have both became more popular. If a choice is a toggle, one size nobody very well it fits.
So vim is verb-noun for simple things, but if you want, you can use visual mode if you’re doing something more complex or just want visual confirmation first.
Sometimes when I don't realize I'm in insert mode, I jump around the document and don't know what just happened. Visual cues in-between would have been nice, so I don't always feel as surprised as I do, lol.
Although I don't know if in that particular fiddly case it would have any benefit.
However, recently I've repented my errors. Having discovered that insert mode <M-Key> functions as normal mode <Key> and moving away from the visual mode whenever possible, I realised that despite the touted simplicity of the selection-action model, there is much cognitive benefit to the vim-way, in making keys function as one bigger conceptual step, combining the motion and the verb into one inseparable unit.
Compared to using visual mode, I no longer wait to look at previews then continue, but simply keep typing away, one command after next, trusting that my machine will follow, it catching up the 'buffer' of my commands at its pace. This truly helps me feel much more connected with my work at hand, 'feeling' my text, not going back to seek at what I expect already, and forgetting about the details. Getting used to performing actions in just one step, albeit a bigger one, allows me to think more effectively about how I edit my text. Conversely, to allow only the expression of 'simple' text concepts does not reduce my cognitive burden, as I would need to, and be thinking of, how to use 'simple' text motions/selections to emulate more complex ones anyway.
On another note, I've finally found myself embracing vim's window management, terminal, buffer management... I'm in awe of the way that vim has gently paved for me, all along. Beyond minimalism, as a shell/terminal multiplexer, vim is great.
https://github.com/helix-editor/helix
But if you're on a blank line, it will delete the next line, not the current line.
If you can figure out why this is, then you are close to understanding how kakoune manages the concept of "line" and "cursor" and "selection", but for me this is an abstraction gap too far. I can't make the conceptual leap. And once you understand the line/cursor/selection model, you see that this is unfixable.
Oh well, maybe Helix is the way.
as noted nearby, vim's visual mode provides a similar interface as standard
No, it wasn't, and hasn't been since the 90s (most of the gvim code was written by others back in the day, to give an example of a large body of code not written by Bram). There have been many people contributing, and some of them for years.
Yes, Bram was the BFDL and the only one committing patches, but don't confuse that with "one man show".
I love Vim, and although my usage is totally vanilla these days, I use Vim plugin for VSCode which is awesome (lack of :norm is the only downside I've found).
Vimium for Firefox is also a must-have https://addons.mozilla.org/en-CA/firefox/addon/vimium-ff/
Built-in multi cursors and autocomplete without fiddling with plugins is wonderful, and the in-editor discoverability and documentation is great.
It retains Vim's spirit of minimalism but cuts out a ton of cruft without constraining itself to any kind of backwards compatibility.
I use Kakoune as my $EDITOR and VS Code with Dance for software development. I think Dance does a great job of leveraging Kakoune and VS Code's strengths. I wish there was an equivalent for Intellij as well.
https://marketplace.visualstudio.com/items?itemName=gregoire...
True, until you need it. And you'll usually pull out ed when any other editor fails :D One example is an extremely slow ssh connection. For those who can recall, when SourceForge allowed ssh access, running vi/vim was a PITA if you wanted to edit something. But not with ed.
The second example of where ed is unmatched is scripting - it has the same "interface" for interactive editing and scripting (it uses the same commands and command sequence). Someone also mentioned (can't find source of the quote) that the same trick is helpful when you write a book because you can easily print ed command sequence readers can repeat and follow your examples, which isn't the case with any other visual editor. You can write unit tests to validate those things in case you want to ensure your book examples actually work.
I have been a VI user my whole life as a result (I worked for Manx in the late 80's, and their flavor of VI was my first real taste of text editing).