Using a count for a motion should select all text traversed

[Omnikar]

Currently, using a count for a motion, such as 2w will behave exactly the same selection-wise as pressing w twice. I think this should be changed so that using a count for a motion will select the text traversed by all repetitions of the motion; so 2w will behave like v2w. This would allow for operations like 2wd as a counterpart to d2w in Vim.

[pickfire]

I have thought about this in the past. Both way seemed to work for me.

[cessen]

2w will behave exactly the same selection-wise as pressing w twice

I'm not sure I follow why that's undesirable. That's how most commands behave: the number prefix is simply a repeat count.

so 2w will behave like v2w.

But isn't that what v is for?

[sj4nes]

The Kakoune behavior could be described as "Always Be Selecting". 2w selects the next two words--the movement of the cursor is a side effect. I find that if the highlighted selection is too broad or want to reset it, I just click Space, and the anchor snaps back to the cursor in its current position (in Kakoune).

When I use v in Helix a stumble for me is how to easily cancel the highlighted selection to start over with the current cursor location.

[archseer]

2w selects the next two words

kak: 2w selects the second word for me, whereas 2W will select two words.

When I use v in Helix a stumble for me is how to easily cancel the highlighted selection to start over with the current cursor location.

I think you can ESC to leave extend mode, then ; to collapse the selection. There's also this proposal: #461

I also wondered if ESC in normal mode could be used for this. So ESC ESC would exit extend mode, then collapse the selection.

[cessen]

I also wondered if ESC in normal mode could be used for this. So ESC ESC would exit extend mode, then collapse the selection.

For what it's worth, I map Esc in normal mode to keep_primary_selection. I kept intuitively pressing Esc in normal mode thinking it would clear multiple cursors, but when all secondary cursors were off screen I couldn't tell they were still there, and I'd happily keep editing away. It resulted in many instances of messed up files that were painful to fix while still retaining the (intentional) edits I had made.

I basically think of Esc in normal mode as "get back to a 'clean slate' editor state". Ideally I'd like that to a be a single cursor, but reducing to the primary selection is close enough for now.

[Omnikar]

On second thought, I suppose the way it works now is actually fine.

[pickfire]

I realized I find this useful now, can we reopen it?

I find myself pressing v way more than ;, almost had to press v every time, sometimes I know the count, I wish if I press the count it will select all the way from current position (not extending) so I can perform an action on this. The behavior will be similar to current 10xd (to delete 10 lines) rather than v10xd. So every time after a movement, the whole thing will be selected rather than the last thing so user can perform action on the whole thing.

[EpocSquadron]

I'd be willing to trial this if there's a branch somewhere I can pull down.

[sudormrfbin]

I'd be willing to trial this if there's a branch somewhere I can pull down.

@EpocSquadron there's #1570 open now.

[rhogenson]

It would be cool if {count}k or {count}j could select count+1 lines upwards or downwards. Then things like vim's d5k is just 5kd instead of the current awkward v5kXd

[winterqt]

The interesting thing is that if you do 5]p, it'll select five paragraphs, instead of jumping five paragraphs down like ]p+5<alt>. does. The inconsistency is a bit strange -- is this intentional?

[pickfire]

No, haven't got the time to fix it yet, coming back to this soon. #1570