Word movement select from first range

[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

Consistency check TODO

• f / t / F / T
• ]p
• ]f

[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.