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.

Possible to learn other languages, it is. Spoken by all people in the world, Germanic languages are not.

Yoda you sound like.

It was interesting to me just how much Subject-Object-Verb (SOV) vs Object-Subject-Verb (OVS) along with all the other permutations of the 3 exist around the world.

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 noticing that I'm in insert mode isn't something I can remember struggling with.

There are different solutions for it:

- Obsessively press escape so you're always in normal mode

- Style the statusline so it's very colorful when you're not in normal mode

- Have the cursor be "fat" when in normal mode and "thin" when in insert mode (isn't this the default?)

Even though I've been using Vim for 15 years or so I also enter visual mode for some commands. It's quite useful, but not necessary all the time (like di" for instance).

Mapping escape key to another key is always useful

or use a vim-clutch

If you have a reasonably long `updatetime`, you could try something like `autocommand CursorHoldI * stopinsert`.

On both vim and nvim, updatetime is 4 seconds, so if you have 4 seconds of inactivity that autocommand will automatically put you back into normal mode.

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 :)

https://github.com/helix-editor/helix

Here's a rebuttal, why kakoune's model might not be better than vim: https://github.com/noctuid/dotfiles/blob/master/emacs/editin...

You can't rebut the need for such a fundamental UI design feature like immediate feedback by saying you don't need immediate feedback

Yes you can; if you don’t need immediate feedback then immediate feedback isn’t a fundamental UI design feature. You can’t dismiss the rebuttal just by stating that it’s “fundamental” as an axiom to someone who thinks it isn’t.

Of course I can dismiss it, pretty easily: I do need that feature, and yes it's fundamental to any UI in computers or real life, and if he doesn't - I don't mind and don't really care since I'm not talking about HIS needs (or yours personally), I'm discussing his dismissal of MINE (and that of kakoune's devs and whoever else values such feedback) and your characterization of that dismissal as some kind of rebuttal

(also statements like these

> Deleting the current word, sentence, or parentheses block does not involve uncertainty

are obviously false, of course it does, there are different types of w/Words (and different separators, and those separators could also be conext-dependent), many nested blocks you might not be immediately aware of borders of, and also with sentences you might not know exactly where a period is, etc., so there is uncertainty in every such case, so again he's just saying there is no need when there is clearly one

And that uncertainty only grows with muliple selections

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.

Oh well, maybe Helix is the way.

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.

prospective vim-learners should note that kakoune style is a dead end

as noted nearby, vim's visual mode provides a similar interface as standard

One major drawback of that model is that it makes textobjects harder to use and are often relegated to more obscure commands.