Making "x" extend selection

[premell]

In the keymap discussion thread I wrote some suggestions of how to improve the keybindings of Helix https://github.com/helix-editor/helix/issues/165#issuecomment-1033690249

Many of my proposed changes are subjective, however I think my suggestion of making x into line wise select mode doesn't have many downsides. By that I mean changing "x" into "vx".

The reason we need a visual mode at all is because the selection keys are also movement keys, which means you a way to determine if the user wants to extend the selection or simply move. But "x" isn't a movement key, so I cant think of a single use case where you would want to use "x", but also wouldn't want to extend selection. Either you use x to simply select the line for an operation like "d" or "y", in which case making "x" into extended selection doesn't matter. Or you want to select select multiple lines, in which case you need to use "vx". Also it doesnt really break consistency since "x" is a quite unique key already.

I might be wrong or missed something though, so I'd be happy to hear your thoughts

[dead10ck]

I'm very confused by this suggestion. vx is not a line wise mode, at least not as that term is used in vim. vx would simply turn on select mode and then select the current line. After that, moving the cursor up and down does not select whole lines. Helix doesn't currently have a line wise select mode. If you want to select multiple lines, you would hit x repeatedly, or v, then move the cursor up or down to the desired line, then x.

[premell]

Okay sorry my bad, I misunderstood how vx worked. However I don't think it changes that much, I still think x should be vx, because there is no situation that I can think of where you wouldn't want extended select when you use x.

[dead10ck]

I do this all the time. xd to delete a line, xy to copy it. Having this start select mode would be super annoying.

[NNBnh]

I've read this issue yesterday, at first I think this gonna be annoying too but then I realized that delete/copy in select mode will auto go back to normal mode so there won't different any quick linewise action like xd, xy...

[premell]

I've read this issue yesterday, at first I think this gonna be annoying too but then I realized that delete/copy in select mode will auto go back to normal mode so there won't different any quick linewise action like xd, xy...

Yes exactly! Either you want to do an operation (which leaves extended selection mode), or you want to move in which case you want extended select mode (otherwise there was no reason to hit x in the first place

[premell]

I do this all the time. xd to delete a line, xy to copy it. Having this start select mode would be super annoying.

I think we are misunderstanding each other. This change would not have any affect on xd or xy. I explain more in my other reply to @NNBnh

[dead10ck]

Oh I see, yeah, you're right, this wouldn't affect quick line operations. Still, I don't really understand the improvement it makes. If you want to select multiple whole lines, why bother pressing x at the beginning of the motion at all? Why not just hit v and start moving up or down to the line you want? What is the difference between vkkkx and vxkkkx?

And also, I think if you really wanted this, you could make your own key binding for it.

x = [ "select_mode", "extend_line" ]

[premell]

One small note, if one were to change it to multi line highlight you wouldn't have to do vxkkkx, you'd simply do xkkk, which is one less key and is more intuitive than vkkkx.

Anyway it was my bad that this got confusing, since I mentioned multi line select in the beginning. However I just want x to behave as vx does currently. Because there is no situation in were x is preferable to vx.

Now I would also like if X was multi line select, but that's an issue for another day.

"And also, I think if you really wanted this, you could make your own key binding for it."

I mean this argument can really be made for all keybindings. But if there is a keybinding that is better than another, why not make it the default? I even think this would be more intuitive, so I don't think that's a good argument either

[dead10ck]

Ok, this

One small note, if one were to change it to multi line highlight you wouldn't have to do vxkkkx, you'd simply do xkkk, which is one less key and is more intuitive than vkkkx.

does not have anything to do with this

However I just want x to behave as vx does currently. Because there is no situation in were x is preferable to vx.

because there is no linewise select mode. That is not what vx is. Suppose you have the following text, and [] represents the selection

Lin[e] 1
Longer line 2

Then you press vx, you end up with this

[Line 1]
Longer line 2

Then you press j, you end up with this:

[Line 1
Longer] line 2

To select both whole lines, you have to hit x again

[Line 1
Longer line 2]

Now let's start over

Lin[e] 1
Longer line 2

Press vj, you end up with this:

Lin[e 1
Long]er line 2

To select both whole lines, you have to hit x.

[Line 1
Longer line 2]

You get the same result as if you hadn't pressed vx.

It seems like what you're asking for isn't a new key binding with the existing functionality; it seems like you're asking for a new linewise select mode feature. I wholeheartedly agree this would be an awesome feature. But it's a completely different request than changing a key binding.

[premell]

Once again I am sorry that I made this confusing. This has nothing to do with line wise select mode. I was only talking about line wise select mode because i misunderstood how vx worked. I dont want to implement line wise select mode (at least with this issue), I simply want x -> vx. So that if you want to select one line and a bit of the next line you can simply use x instead of vx. This isnt as useful as line wise select mode, but it does come up. And as I've said I think there is no downside and its more intuitive.

So this change does not help if you want to select several entire rows, but it does help if you just want to select part of rows.

[mdaffin]

I find the behaviour of x to be a bit weird. Why is it not like all the other movement keys. Like if you start with

the fi[r]st line
the second line

And hit w you get

the fi[rst ]line
the second line

And if you hit w again you get

the first [line]
the second line

But with x it extends the selection rather than moving it - which is feels like inconsistent behaviour. Like with:

the fi[r]st line
the second line

Then hit x and you get

[the first line]
the second line

Then hit x again it extends the selection rather than moving it so you get:

[the first line
the second line]

But I would expect, going of the other movement keys do to get

the first line
[the second line]

And then like the other movement keys if you want both lines selected you could do vxx.

[valpackett]

But I would expect, going of the other movement keys do to get

Yep! That's how x works in Kakoune, and Helix's current x is (shift-) X in Kakoune.

[the-mikedavis]

There was some discussion of this on the Matrix recently, plus Kakoune recently changed x. I prefer the current behavior where x always extends the selection but I think there should be a command that extends the selection to the full line without continuing to extend (i.e. matching the new behavior of x in Kakoune) so that those who prefer that may re-map their x to it. (Afaik we don't currently have a command that performs this behavior.)

[valpackett]

there should be a command that extends the selection to the full line without continuing to extend

That's the current Helix X (extend_to_line_bounds) isn't it?

There should be a command that extends the selection to the full line but if the full line is already selected, instead of continuing to extend, selects the next line.

[the-mikedavis]

Oh dear I should really read the keymap, X is exactly what I was thinking of 😅