I vastly prefer the Vim way of action+selection to kakoune way of selection+action. Here is a short write-up (not mine) about why kakoune model is not that appealing [1].
So helix is not for me. My ideal editor would be a modern re-implementation of the Vim way of doing things, probably using different keys, probably thought-out more, probably more light-weight. But for some reason no editor wants to go there. They either break from Vim's model (kakoune, helix) or follow Vim along with all it's flaws (Neovim, Vis).
Great write-up. Hate that I gotta press semicolon to drop the preceding selection that's a side-effect of my intent to merely navigate somewhere.
Neovim, though, if it wanted to distinguish itself to novices, should integrate which-key.nvim as well as the behavior in the annotation plugins you listed in the article to make things more obvious.
Vim's big fail is discoverability, not the editing model. You can run through past (Neo)vim threads on HN and consistently find 10+ year vets discovering some new behavior from the TFA of the thread. Perhaps some sort of predictive ChatGPT-based solution would expedite that effort since Vim has a lot of behavior to surface from its manuals. There's :helpgrep yes, but a novice still needs to know what to do ask.
This is why I'm a big fan of efforts like Fish, cause it does a great job surfacing CLI tooling behavior OOB just by pressing tab and navigating for what you want, with descriptions, in place
> They either break from Vim's model (kakoune, helix) or follow Vim along with all it's flaws (Neovim, Vis).
I am sincerely curious of what flaws from Vim has Vis inherited, in your opinion.
I have the impression that the design idea of Vis is taking only the modal design of Vi (not Vim), plus the structural regular expressions of Sam, then make it as clean as possible with programmability via Lua plugins.
In fact, the state non-goals [1] seems to clearly distant itself from Vim.
Vis inherits default keymaps. I prefer the way kakoune tried to clean them up by - for example - putting all the "goto" commands under "g" (where Vim has H, M, L, g;, G, gg, $, 0, ^, etc) and all the "view" commands under "v". Such rearrangements make a lot of sense and to me were more intuitive right away, even after a decade use of Vim. Then there are things like ";" and ",", W, B, E, and gE (where something like w, W, e, E would be a lot more obvious), etc. Vim likely acquired those incrementally and that's why they are all over the place. But if an editor were to start from scratch they could be re-arranged in a more logical order. Yet every vim-inspired editor takes Vim defaults for granted.
So helix is not for me. My ideal editor would be a modern re-implementation of the Vim way of doing things, probably using different keys, probably thought-out more, probably more light-weight. But for some reason no editor wants to go there. They either break from Vim's model (kakoune, helix) or follow Vim along with all it's flaws (Neovim, Vis).
[1]: https://github.com/noctuid/dotfiles/blob/master/emacs/editin...