I'm totally fine with (re)learning new tools, but having given Helix a solid try found the noun-verb model worse; the visual feedback is fun but distracting, particularly when you're moving around reading code. For it you give up things like repeating edits easily (bound as '.' in Vim). There's also a statefulness to Helix's model that isn't present in Vim; whereas in the latter I only have to care about where I _am_ in the file as I'm making my edit, in Helix I have to care about where I've _been_ because that dictates what I've currently got selected. See my other comment for details.

I want an editor with OOTB configuration and a modal editing paradigm (probably Vim's) that isn't constructed around visually synchronizing every edit action. Doing the latter means relinquishing what's good about an editing language, which is that you needn't actively think about edits so much. It's not about speed, but freeing up mental resources to think about the more interesting programming tasks at hand. Editors that demand more attention are doing a worse job.

surprised helix doesn't support the . key - is that incompatible with its interaction model somehow?

Yes, its model is that you make a selection and then act on it. After the action happens there's nothing selected. The editor can't infer your intent in making the selection, so there's no reasonable notion of repeating the last edit. You can separately repeat the last motion or last action, but not the whole edit---which of course isn't as useful.

Helix would _ideally_ like you to tell it ahead-of-time everywhere you're going to make an edit by selecting all the edit points with multiple cursors, without a great option to fire edits on the fly. Ironically I found this worse for visual feedback when making larger edits---where it's most needed---because there are usually edits happening off screen, instead of only at the point of the cursor (where the latter can be easily repeated).

It ends up feeling less interactive and more like I'm using a batch editor due to this, which (I think?) was not its intention.

In that situation, what I do is essentially save a macro (recording the selection and the edit) with `Q` and then `q` becomes my equivalent to `.`

Good note; there's almost always a (somewhat less convenient) workaround. I find the visual feedback that induces these compromises actively annoying, so don't want to give up anything for it. Different strokes, of course!

Hmm

The existence of a repeat or “magic” key is one of the more interesting developments alternative keyboard layouts designs. The use case is slightly different of course.

But as an extremely heavy user of vim repeat and macros for the last two decades, it strikes me as a wee bit audacious to so completely dismiss its utility.

I think noun-verb is worse; I'm unsure where the idea comes from that Helix's (or Kakoune's) editing model is better. Bear with my short rant. :-)

I don't want or need pre-emptive visual feedback on every keystroke, because it's a tool I use every day. I want an editing language that allows me to develop a mental model of it, so that I can _avoid_ round-tripping most edit actions visually. The primary advantage of the Vi editing language has never been speed (though that tends to be a secondary one), it's that it saves you from thinking about editing. Visual feedback also adds noise; it's especially distracting when you're moving around reading code. It's not an automatic win except when you're learning. Finally, if I really need it, I'm using a modal editor! I can simply switch into visual mode for complex edits. That's the modal solution.

And in exchange for (ime, annoying) visual feedback I have to give up things like the repeat last edit '.' key, and operator pending mode (see :omap), and more... which isn't palatable to me. Of course, everyone works differently; different strokes. But it's not obviously better, in a lot of ways.

I _am_ envious of the complete default configuration Helix has. Though it seems like that's planned from Neovim in the near future, alongside multicursor (filed under 'super macros'), looking at their roadmap.

I strongly agree.

I have mixed feelings about Neovim adopting multicursor. Doesn't setting multiple cursors and then acting on them belong in the noun-verb camp? Unless you call it multivisual, of course!

damn. noun verb makes spell casting visually noisy and... as if you didn't know your spells and havent yet adopted 100% typing accuracy --- the feedback (visual noise) just makes you weak anyways. just `u` and helix inherently loses `.`