Word movement select from first range, remove unnecessary v

[pickfire]

3w currently selects the 3rd word, this changes the behavior to select
all 3 words rather than just the last.

One of the thing mentioned in #165.

Fix #536

Motivation

Many common motions require prefixing with v for count-based operations. For example, v3wd deletes three words.

This PR removes unnecessary uses of v where its presence makes no functional difference. It's unlikely users interpret 3wd as "delete the third word", 2wwd aligns better with typical mental models while using the same number of keystrokes.

Consistency check

• f / t / F / T
• ]p
• ]f - no preference on this, not changing it, I feel like it's weird to 2]f to select 2 functions down from current position
• A-n / A-p / A-i / A-o - keeping, it seemed like these tree-sitter movements affect the whole current selection, I don't get the use case to select until the next two tree-sitter nodes
• gh / gs / gl - useful to replace/delete till start or end of line, the not obvious ones would be gs from start of whitespace which includes a character, why would someone want to delete till the first character? gs v d just to delete whitespace (people could just w d instead)?

Common operations

Operation	hx new	hx	vim	kak
Delete 3 word	3wd	v3wd	3dw	3Wd
Delete 3 lines down	3xd	3xd	3dj	2Jxd
Delete 3 lines up	v2kxd	v2kxd	3dk	2Kxd

Side note: https://delapouite.github.io/kakoune-explain/ and https://delapouite.github.io/kakoune-explain/keys.html seems cool

[Omnikar]

This should close #536.

[dead10ck]

Looks good to me!

[pickfire]

This should close #536.

I think not exactly, this only fixes 3w and not 3l.

[pickfire]

I think I would at least like @archseer to review this.

[archseer]

I'm still undecided here. With this change 3w stops behaving like www (now 3w in both normal and extend mode v3w behave the same). Since the workaround is in movement.rs, it's not possible to get the old behavior without repeatedly calling the method either.

[pickfire]

I'm still undecided here. With this change 3w stops behaving like www (now 3w in both normal and extend mode v3w behave the same). Since the workaround is in movement.rs, it's not possible to get the old behavior without repeatedly calling the method either.

I think this is better because when you think 3 words, then you press 3w then it will select 3 words, if you want to extend to amend stuff can always 3wv2w.

One use case, it's very easy to say you want to delete 3 full words, then 3Wd can delete exactly what you think of. But on the other hand, with extend you need to v3Wd. Or if users don't know can still vWWWd.

For me, I think this builds on top of extends. At least I never had the need that 3w select only the last word then I delete that.

[cessen]

Personally, I'd rather leave it as-is, where 3w behaves the same as pressing w three times. I like v mode being the all-encompassing way of extending selections with other commands, because it makes everything easy to reason about.

For example, there was a recent(ish) change that initially surprised me, but which after getting used to I'm quite happy about, where shift-n no longer extends selection on search results, and instead you go into v mode first for the same effect. There's a consistency and composability about it that I appreciate.

Having said all of that, I don't feel strongly about this, and I acknowledge that sometimes too strict adherence to consistency can harm practical usability. So I'm not specifically opposed, but just have a personal preference to leave as-is.

[pickfire]

Having said all of that, I don't feel strongly about this, and I acknowledge that sometimes too strict adherence to consistency can harm practical usability. So I'm not specifically opposed, but just have a personal preference to leave as-is.

I think if that's the case, we can keep it consistent as in 3w or whatever movement including count will be taken as the next selection if user is not in extend mode. I think the only downside of leaving as-is is that the current behavior is useless without extend.

[dead10ck]

I've changed my mind on this too, I think 3w should be the same as pressing w 3 times. Select mode should be used for this case.

[pickfire]

I've changed my mind on this too, I think 3w should be the same as pressing w 3 times. Select mode should be used for this case.

Is it due to consistency? Like 10l currently select only one character? I am thinking of making it consistent such that <count><motion> always results in all of them being selected, instead of just the last motion.

Why is this? In my train of thought, in vim I can do dw which means delete a word, and 2dw means delete two words. Helix I have to do wd to delete a word, and v2wd to delete two words, I am thinking count acts as an annotation to select how much, instead of repeating the last action which is more surprising to me.

[dead10ck]

Hmm. I see what you mean. So the difference is in how one interprets the count, i.e. does 3w mean "select the third word", or "select the next 3 words"? I think both are valid interpretations, but for consistency's sake, I think we should pick one and make it that everywhere that is relevant.

So I guess, what are the pros and cons to each? Right now one can do it either way: v3w makes it possible to select the next 3 words. However, if we change it to "select the next 3" to be more vim-like, then we save a keystroke, but I think we actually lose the ability to do select the third word; 3w and v3w become redundant.

Personally, I almost never use counts, so I guess I really don't have a strong opinion one way or the other. Both ways of interpretation make sense to me. But it does seem like the current behavior is more consistent on the whole.

[pickfire]

Personally, I almost never use counts, so I guess I really don't have a strong opinion one way or the other. Both ways of interpretation make sense to me. But it does seem like the current behavior is more consistent on the whole.

The new approach can be more consistent once I change the rest, so consistency is not really an issue.

Yes, it does lose the ability to select the 3rd word, but why would someone do that? If it is something very useful, wouldn't vim 3dw delete the 3rd word rather than 3 words? Do you have a use case that you just want to say change/delete nth word?

At the same time, even though this may not be a good approach, people can always do 2wwd to skip 2 words and then delete a word.

One benefit of the new approach over the current approach is that, 2w2wd to skip two words and delete two words, in the current way of doing it, it's 2wlv2wd to do the same, which makes changing n words harder, so the current approach is in favor of doing operations against one object, rather than n objects.

[dead10ck]

Yeah, for sure, selecting the 3rd word is probably less often desired than selecting the next 3 words, and either way, one can still do www. I don't think it's going to have a huge impact on the UX. I don't have a strong opinion on this.

[cessen]

I also don't feel strongly.

(Truth be told, I almost never use the count feature anyway. The point at which the count becomes large enough for me to bother using it is also the point at which I would need manually count the words to know what number to enter, and at that point I might as well just hit w multiple times while manually counting anyway.)

[nxy7]

I'm not sure how important user feedback is to help you decide on how to treat motions in normal mode, but as far as I've seen people are in 2 camps:

1. people that want to select whole motion
2. people that want to treat count -> command as calling command multiple times

In my opinion first is more natural to users, and second to helix maintainers (user is not concerned with how program is made so I think it's more natural to think "select 3 words", and not "use 'w' three times"). I didn't see anyone arguing in favour of 3w selecting 3rd word as functionality (and i've never used that myself, most people in second camp want to keep it as is because of 'consistency', not because they find it useful - at least that's my understanding), so in my humble opinion it would be nice if whole motion would be selected. It would be more in line with what people coming from other editors would expect and would be useful much more often.

[justinlovinger]

There is a pretty good sign in this and related discussions that the current behavior is unintuitive. Almost everyone in these discussions gets the current behavior wrong. v3w, with the current behavior, does not select 3 words. It selects 3 words and whatever was previously selected, maybe 4 words, maybe 2 words if the previous command was b. The actual key sequence to select 3 words, with the current behavior, is wv2w or ;v3w, and yet, as evidenced by discussions on this matter, when someone thinks "how do I select 3 words with the current behavior", they come up with the wrong keys.

[pickfire]

I just noticed there are some keys that did this correctly, such as 2f= will select until the 2nd = which is consistent to the change suggested in this pull request.

[saccarosium]

I think makes much more sense if the counts, actually extend the selection since in most, if not all, cases the user is actually trying to do an action to multiple items rather than multiply the action. Would simply a lot the action on n item without needing to collapse the current selection.

[kaos]

New helix user here, just adding my $.02 worth...

Hmm. I see what you mean. So the difference is in how one interprets the count, i.e. does 3w mean "select the third word", or "select the next 3 words"? I think both are valid interpretations, but for consistency's sake, I think we should pick one and make it that everywhere that is relevant.

👆🏽 This I feel is spot on 💯

So I guess, what are the pros and cons to each? Right now one can do it either way: v3w makes it possible to select the next 3 words. However, if we change it to "select the next 3" to be more vim-like, then we save a keystroke, but I think we actually lose the ability to do select the third word; 3w and v3w become redundant.

As a new helix user (also new to modal editing, so not a previous vim user either) I find it logical to use v3w to select three words rather than just 3w as I see it being the same as www (just repeat the command).

I think it would be a mistake if prefixing commands change what they do. So with this, w should also extend the current selection.

But then again, if too many commands extend the selection in normal mode, then what's the point of the selection mode?

--

Yes, it does lose the ability to select the 3rd word, but why would someone do that?

Only because we wouldn't use it, doesn't mean it can't be useful to someone else.

If it is something very useful, wouldn't vim 3dw delete the 3rd word rather than 3 words? Do you have a use case that you just want to say change/delete nth word?

I don't know vim, but I guess 3dw is the same as dwdwdw? (Consistency is king.)

Also, I hope helix isn't restricted to copy how vim solves things, but are free to come up with it's own implementations?

---

Edit:

To summarize: I'm in favor of keeping it as-is.

[pickfire]

As a new helix user (also new to modal editing, so not a previous vim user either) I find it logical to use v3w to select three words rather than just 3w as I see it being the same as www (just repeat the command).

Just so you know, this change will allow you to keep the existing behavior where you can still use v3w and not be affected by this. So this improves those who wants to improve their current workflow with more consistency as well as being more ergonomic.

[sicher]

I think it would be a mistake if prefixing commands change what they do. So with this, w should also extend the current selection.

But then again, if too many commands extend the selection in normal mode, then what's the point of the selection mode?

I suppose 3w would not extend any current selection. It would remove it and instead select 3 words. That is how 2f= behaves currently.

I think I am in favour of treating the numeric prefix as a quantifier of "how much/how many" instead of a hard repeat-count (where it makes sense). Would it be possible to create a separate prefix notation for strict repeats? Like #3w or something that would just repeat the command?

[pickfire]

I have been using this personally for quite some time years, seemed like the word change is the only thing that felt missing.

This should be good for review now. 😆

Hopefully @archseer and @the-mikedavis are still around to help review. :D

[justinlovinger]

Would it be possible to create a separate prefix notation for strict repeats? Like #3w or something that would just repeat the command?

#3w would be equivalent to 2ww, which is the same number of characters.

[pickfire]

#3w would be equivalent to 2ww, which is the same number of characters.

Not really, #3w have to type 4 characters in most keyboard layouts (# requires shift), and you have to hold a single character which is slower. 2ww is definitely faster and easier to type.

[kaos]

As a new helix user (also new to modal editing, so not a previous vim user either) I find it logical to use v3w to select three words rather than just 3w as I see it being the same as www (just repeat the command).

Just so you know, this change will allow you to keep the existing behavior where you can still use v3w and not be affected by this. So this improves those who wants to improve their current workflow with more consistency as well as being more ergonomic.

I think you missed my point of:

[...] I see it being the same as www (just repeat the command).

That is, I could type 3w anticipating to select the third word, not three words.

[pickfire]

That is, I could type 3w anticipating to select the third word, not three words.

Why would you think that way? How did you come up with this idea?

I have seen lots of example a number followed by something won't be this way. Some examples:

• In vim, you do 3dw which stands for delete 3 words, not delete 3rd word
• In duration, 3d you can think of it as 3 days, not 3rd day as seen in duration
• In English, you say 3 dogs for 3 dogs, and 3rd dog for 3rd dog, I never seen 3 dogs meant the 3rd dog, even in Chinese or Japanese, there are clear distinction where number clearly meant number and not nth

What is your reference point? At least, I never thought about it, or IMHO it is more intuitive for 3wd to delete 3 words.

[kaos]

That is, I could type 3w anticipating to select the third word, not three words.

Why would you think that way? How did you come up with this idea?

It's not my idea, it is how it currently works in Helix; which makes sense to me as it is.

I have seen lots of example a number followed by something won't be this way. Some examples:

• In vim, you do 3dw which stands for delete 3 words, not delete 3rd word
• In duration, 3d you can think of it as 3 days, not 3rd day as seen in duration
• In English, you say 3 dogs for 3 dogs, and 3rd dog for 3rd dog, I never seen 3 dogs meant the 3rd dog, even in Chinese or Japanese, there are clear distinction where number clearly meant number and not nth

This is comparing apples and pears. Helix is not vim nor are we talking about durations or counting nouns.

What is your reference point? At least, I never thought about it, or IMHO it is more intuitive for 3wd to delete 3 words.

My reference point is consistency, and that the number here is used to indicate how many times we want to run the following command. (So agreeing with you here, the number is meant to be a number and not nth. But it is how this number is used that can turn into having the effect of selecting the nth of something.)

The w command is "move to start of next word". I interpret 3w as "move to start of next word, three times", that is I end up at the start of the 3rd word, leaving the previous two behind. So the difference here I think is how to treat the current selection. Using a bare w repeatedly the selection moves with the cursor, only selecting the most recent movement. Here, my view is that in NORmal mode, 3w ought to do the same as www for consistency (that is what I am expecting, the prefix number merely tells how many times I want to repeat the following command.) rather than selecting the next three words. If I want that, I first press v to enter SELect mode, so to select three words, I type v3w.

The reason I responded in the first place was due to this statement:

[..] this change will allow you to keep the existing behavior where you can still use v3w and not be affected by this.

Which is true, taken verbatim, but I am affected for my use case of 3w to select the third word. (I see that the way I phrased my sentence preceding that, it seems I was primarily using v3w, but I was equally pushing for the expectation for what 3w does.)

[cessen]

As I said up-thread (back in 2022!) I don't actually have a preference one way or the other, because I rarely (if ever) use number-prefixing. However:

@pickfire

Why would you think that way? How did you come up with this idea?

I think @kaos's proposed behavior is perfectly valid and understandable. It's just interpreting 3<command> as "execute <command> 3 times in succession". It's simple, self-consistent, and predictable.

(Edit: I say his "proposed" behavior, but IIRC that's how it already behaves in Helix.)

[the-mikedavis]

I also don't really have a preference here: I also rarely, if ever, use counts. A count meaning that the command is repeated n times makes sense to me conceptually though. I also think it's reasonable that a count means different things for move_next_word_end and extend_next_word_end. Ideally select mode should not really be a full mode and should be more like a minor mode which replaces normal mode's movement commands with ones that extend, and you should be able to put together Kakoune's keymap (where shifted keys extend) and drop select-mode altogether.

[pickfire]

I work on this suggestion as I found v to be a bottleneck everywhere, like everything have to do v when it could be 2wd, currently 2mapd will delete 2 paragraphs without pressing v which I think is nice, but for word movements it needs to press that extra v.

Count felt useless and I have to fall back to vwwwd, at the same time I think move number 3 times I think it can be easily replaced with 2wwd which you skipped it first time and being faster to type (double press) and can save v (same type press as v3wd).

[rauletaveras]

I am a user with no prior vim history, and I can say that, among the small things that sometimes make Helix feel weird, this is by far the largest. Having 3w not drop what I have and then select 3 words makes Helix not feel like a selection-first editor at all in these cases (note I mainly write and edit prose, not code). I'm happy discussion is still alive on this because I'd love it to be "fixed" to be more intuitive. Furthermore, as @justinlovinger pointed out, v3w does not in fact select the next three words, but includes those words plus whatever we have selected. That means we have to collapse selections a lot more often than necessary for ergonomics. This is probably not an insignificant source of confusion for new users (including me, though I'm not that new anymore) between what "select" and "extend" mean in command names.

Edit: Example of difference from v

I wanted to add a clear example. Say we take have the following line, which [ representing the anchor and ] representing the head of the selection

//! Selections[] are the primary editing construct.

If we want to select "Selections are the", a beginner like me used to try bv3w. The problem, of course, is that v keeps the anchor from the previous selection, so, after the 3w, the selection ends up like this

//! Selections[ are the ]primary editing construct.

The intended outcome requires collapsing the selection after b, resulting in the awkward b;v3w. This applies even if we don't use the count; you need b;vwww. This PR changes the behaviour, such that b3w results in the intended selection:

//! [Selections are the ]primary editing construct.

Which is much more ergonomic and maybe intuitive for a beginner (I was that beginner).

[std-enigma]

I’m honestly surprised this discussion hasn’t already reached a conclusion or been closed.

As someone who comes from Vim but understands Helix’s goals, I think it’s important to note: Vim’s d3w (or v3w) behavior is not the result of a deliberately designed “scale the motion” feature — it’s just how its operator–motion system works.

In Vim, d3w literally means:

• Delete → repeat the w motion 3 times.
• The w motion returns a range each time. Chaining three of them produces a contiguous 3‑word range as a byproduct.

People often think “Vim has a built‑in delete‑3‑words command,” but it’s really the inevitable outcome of repeating a motion that returns a range.

Helix is a different paradigm:

1. Find your selection first (motion-first).
2. Then apply the action to it.

Here, 3w really is “do w three times” — and it doesn’t collapse into a single continuous range unless you explicitly start in select mode (v3w).

Changing 3w to mimic Vim’s outcome would:

• Break the clear, predictable “repeat motion” logic.
• Reduce the usefulness of select mode.
• Import behavior from Vim that wasn’t even an intentional design choice there — just an artifact of its command structure.

Helix should lean into its own model, not mimic quirks that only make sense in the context of another editor’s architecture.

[rauletaveras]

Thank you very much for your contributions on the technical side! I was not aware of those details about Vim's implementation. I completely agree Helix should lean into its own vision instead of mindlessly replicating others'.

However, at least in my case, that's precisely why I advocate for this particular change. Part of the vision (https://github.com/helix-editor/helix/blob/master/docs/vision.md) says that Helix should be "selection > action". As I read it, while it strictly says only "you must select before acting", it implies an editing experience where selecting is a first-class workflow. The current behaviour of these movement keys doesn't offer that, and it has evidently been a pain point for many before (including, perhaps especially, beginners) (as recently as 3 weeks ago!).

Now, I haven't used Vim/Neovim, but as I read their docs, it seems they're easily capable of selection-first contiguous (putting aside multiple cursors/selections) editing by using their "visual mode", also activated with v. If you insist on using visual mode first, it seems to me you can replicate Helix's select mode simple motions.

So, in this aspect of editing experience, where does Helix improve upon an ostensibly "action-first" editor? It seems mainly to constrain the user option-space by disallowing action-first editing while still requiring, for selections beyond one (1) immediately-contiguous movement unit, the same workarounds that that action-first editor needs to use for its selections. In this sense, Helix seems to already borrow from Vim too heavily instead of leaning on being selection-first.

Mind you, I repeat I haven't used vim because I don't want to be told "just go use vim then". I wholly buy into the Helix way of doing things and think it does better when it leans into it. This is for me a step in that direction and improving on what's already there.

[rauletaveras]

Upon further reflection and studying the codebase a bit more, I believe the disagreement might stem from a fundamental mismatch between the selecting and editing model some users (like me and @pickfire) expect and what other users (like @kaos and @std-enigma) and the code expect.

In is particular case, it happens that word movements seem to be somewhat of an inheritance from past models: for the code and latter camp, we can illustrate it by saying w is primarily about movement; w means "move to next word start", and the fact that it selects until then is (effectively) a side-effect convenience (though intended), inspired by Kakoune, to facilitate small edits based on Helix's select-first-only workflow.

Users like me, some of which don't have experience with vim (where movements don't inherently select), see that w selects until the start of the next word and understand it to be primarily about selection—i.e. "select a word" (helped by the mnemonic)—such that w means 1w, namely "select the next 1 word"; we thus expect 2w to mean "select the next 2 words" and so on. This is crucially not the same as "extend selection to include the next 2 words", which is the behaviour of Select mode (appropriately labeled in the website as "Select/extend mode"). The former creates a "new" conceptual selection that only includes what we told it to now include (how this PR works); the latter adds to whatever we have selected.

The full extent and implications of this mismatch is out of the scope of this PR and I intend to flesh it out in a discussion post soon. However, I hope this can contribute to the conversation if it hadn't been considered before.

Edit: Phrasing.

Edit 2: I found a comment I was looking for, where this mismatch is explicitly articulated: #536 (comment)

[std-enigma]

I still think changing 3w to create a contiguous 3‑word selection is a step in the wrong direction.

Helix already has selection‑first editing with select mode (v3w) — which is equivalent to Vim’s visual mode. If you want a contiguous multi‑word selection, that tool already exists and is consistent with the rest of Helix’s motion model.

Making 3w create one big selection feels redundant when you already have a specific feature built for exactly this scenario. Even worse, it makes select mode less valuable for small movements. Not entirely pointless — but close enough that its role is diminished. The “extra” keypress in v3w instead of 3w isn’t really extra at all — it’s the intended tool for the job. Think of it like using the right-sized screwdriver instead of forcing the wrong one because it’s already in your hand.

If we special‑case 3w to merge into a single selection:

• We break the principle that counts repeat a motion without changing what the motion fundamentally does.
• We introduce inconsistency across motions.
• We add complexity for almost no real gain.

From a developer standpoint, the shortcut (v before 3w) is already there and doesn’t require rewriting motion semantics.

As an experienced Vim user, with the right plugins — especially something like smoka7/multicursors.nvim plus some remapping — you can replicate Helix’s multiple cursors, independent selections, and most of its default behavior without leaving Neovim. Many popular Neovim plugins could technically be done in pure Vim, because Vim’s core has broad, general‑purpose features that can be bent into almost anything if you understand them well enough. But for most people, that’s not appealing — it’s extra effort, extra overhead, and honestly less fun than just installing a plugin designed for that exact job.

Which is why I sometimes ask: why not just make a very niche Neovim distribution — configured with Helix‑style keymaps, core plugins pre‑installed, and default behaviors ready to go? You’d get almost the same result without building a whole new editor. Of course, Helix’s philosophy is still distinct: it ships opinionated defaults — completion engine, LSP setup, treesitter, picker — all essentials for coding. In the old Neovim days, getting all this running was… not fun. Telescope(picker) could take at least 300 lines of config. LSPs were worse. Completion engines were over-complicated — even the “easy” one to configure was Node‑based, filled with dependencies you didn’t ask for, slowing things down. Sure, there was omnifunc (built-in completion function), but configuring it felt almost like a dare. None of this would have been “bloat” if Neovim core provided it, but that’s not how Neovim rolls.

I’ll admit, Helix also has quirks I don’t love. For example, deleting a couple of lines above your cursor can take something like v2kxd — compared to Vim’s more convenient approach. I find this counterintuitive and a bit unpleasant, especially because Vim’s way is baked into my muscle memory. I could easily make an issue for it and propose a fix: add Vim’s visual line mode. It would still fit Helix’s model, just like select mode but limited to whole lines — so deleting 3 lines above would be V3kd. That’s one keypress fewer and makes perfect sense.

But here’s the problem: as soon as that exists, someone will make an issue asking for 3kd to delete 3 lines upward without needing visual line mode, simply because they don’t want to use the intended tool for the job. This is the same philosophical trap as the 3w request — just rotated vertically. And if we caved on that too, bit by bit, all these special cases add up until… congratulations, we’ve built Vim again.

That’s why I think some things should just stay as they are.

On a personal note, I also don’t prefer Helix’s default keybindings. A lot of Vim users trying Helix seem to rebind things back to Vim’s layout. I don’t like using ge to go to the end of the file, but I’ll never bind G to do that because it breaks my editor of choice, way of doing a thing. For many people it’s almost instinctive to port Vim keymaps into Helix — but if you find yourself doing that across the board, maybe the answer is just… use Vim. Still, that might just be how my brain works.

[std-enigma]

Just to add some personal context to my perspective:

Helix tempts me because it ships with so many essentials done right out of the box — LSP, treesitter, completion, picker, clean defaults. There’s no plugin hunt, no dependency maze, and no feeling that you need to spend the weekend wiring things together before writing a line of code.

I love Neovim’s extensibility. In fact, it’s one of the main reasons I keep using it — the feeling that you can turn it into anything with enough creativity. But that same flexibility is its biggest trap. It’s so easy to turn your Neovim config into an art project: a masterpiece you constantly sculpt and polish instead of actually coding. The plugin ecosystem makes this even easier — and harder to resist.

Helix sidesteps that entirely. Fewer knobs, more focus, and no risk of falling down a configuration rabbit hole. It quietly enforces the idea that your editor is a tool first, not a craft project.

And yet… I’m not switching. Neovim is too powerful, too familiar, and too much mine to abandon. My plan is to tear down my somewhat bloated setup and rebuild it from scratch — minimal, purpose‑driven, and as close to Helix’s “everything you need in one file” feel as possible. That way I keep the extensibility I love and stay grounded in the tool I’ve used for years — without being tempted away every time Helix crosses my mind.

[rauletaveras]

Thank you for your thoughtful, thorough response! c:

And I appreciate what you and others mean by the count "changing the behaviour of the motion". I truly see it, and while it's true on a technical level, it's not true from some perspectives: as I mentioned above, it depends on your mental interpretation of what the command is for.

Now, outside the scope of the PR, but after much reading and experimenting, I can confirm the rest of Helix's motion model is not self-consistent (at least in terms of behaviour). As promised, I elaborated my thoughts in a discussion post (#14468) which I would invite you to have a glance at. It's not perfect, but I believe it helps explain why there has been a lot of confusion and shed light on how to move forward from it.

[sicher]

• We introduce inconsistency across motions.

Helix is currently inconsistent and this PR attempts to address that. For instance:

• 3w is treated as www.
• 3txis NOT treated as txtxtx.

(And there are a few similar inconsistencies currently - see the top)

[pickfire]

3txis NOT treated as txtxtx.

Even if this PR is not accepted, I doubt the PR that change 3tx to be txtxtx will be merged. 😆

Side note, some keys like hjkl are deliberately not to be consistent since it doesn't make sense to have k select one line above.