Make goto End of Line / Beginning of Line Select Text

[cyanff]

Currently, almost all movement keys move the caret and select text. The behavior of goto differs from this.
Common operations like goto the end of line/ beginning of line should select text.
Having to enter visual mode first is both inconvenient and inconsistent with the behavior of all other movements.

What The Change Will Look Like

Before

Change to the end of the line: v+g+l+c
Delete to the end of the line: v+g+l+c

After

Change to the end of the line: g+l+c
Delete to the end of the line: g+l+c

[archseer]

Has been discussed somewhere before but I can't find the thread. Same problem as #1570 (comment), it's more usable this way but it's inconsistent with the rest of the goto mappings (gg, ge -- these could be made extendable too. But what about gd etc?).

[sudormrfbin]

Even if it's inconsistent, it's not surprising. I would not expect a goto definition keybind to extend from the current cursor position to the definiton because it doesn't make much sense, but I would certainly expect a movement key such as goto end of line to select since helix is a selection first editor.

[cyanff]

Agreed, some keys are obvious to the user to be non-selecting.
Ex: all the LSP dependant keys.

Additionally, as a user, I would expect common operations like goto EOL/beginning of line to be selecting.
I switched to helix as my primary editor recently and was surprised by the non-selecting nature of go to end of line.

[pickfire]

I think this would be nice as a default, I thought I sent a pull request for this but I didn't, but I did send one for word motion I think. Every motion that user used (3w, 2]p, gl) in which the exact location is known especially in the same file should have that be selected by default. Two modes we have:

• normal mode, the whole new motion will be the new selection
• extend mode, extend/retract the head cursor against the new motion

At least personally when I used helix I did tried like gld and 3Wd and all of them didn't work even though I had did the same thing many times before and it didn't work.

[tmke8]

There is already a difference between gl and gd in visual mode (v): gl extends the selection but gd jumps and the selection remains intact (you can come back to it with ctrl-o). And I think that's the behavior that the user would expect. So, I think the behavior that is proposed here would not be surprising and I would be in favor of it.

EDIT: By the way, you can already get the proposed behavior today with this remap:

[keys.normal]
g = { l = ["select_mode", "goto_line_end", "normal_mode"] }

[mkatychev]

Has been discussed somewhere before but I can't find the thread. Same problem as #1570 (comment), it's more usable this way but it's inconsistent with the rest of the goto mappings (gg, ge -- these could be made extendable too. But what about gd etc?).

So why not preserve any g* as goto and extend emacs shortcuts from prompt and insert to mirror functionality in normal mode, so that Ctrl-e is move_line_end_newline, etc.

Regardless I think it would be nice to have semantic value imparted onto the verbs, right now jump_ goto_ and move_ are inconsistent in what they actually do. Would be nice for each of those prefixes to imply something.

[pickfire]

So why not preserve any g* as goto and extend emacs shortcuts from prompt and insert to mirror functionality in normal mode, so that Ctrl-e is move_line_end_newline, etc.

Emacs keys are not desireable in normal mode, only in insert mode they are valueable.

[archseer]

only in insert mode they are valueable

Even there I think it was a mistake to add so many.

[Zoybean]

I don't remember where I read this, otherwise I'd link it, but I figure it's worth noting that t return and T return are available today to do the proposed select to beginning/end of line behaviour.
Edit: these don't work for the end of the last line (with no trailing eol) or the beginning of the first line

[QiBaobin]

I think they are very common cases, can we use new keys to do this? Like 'H', 'alt-h' or 'alt-I' to extend_to_line_start, ''L', 'alt-l' or 'alt-A' to extend_to_line_end.

[peter9477]

I don't remember where I read this, otherwise I'd link it, but I figure it's worth noting that t return and T return are available today to do the proposed select to beginning/end of line behaviour. Edit: these don't work for the end of the last line (with no trailing eol) or the beginning of the first line

I was just experimenting and not only does this not do what you'd probably want for this case if the line is empty (since the cursor will already be on the newline, so selecting till next newline will be the end of the following line), but I think this also doesn't work properly (bug?) in the case of a line with a single character (plus newline). If you're on that one character (whitespace or not) and do t Enter you'll select past your line to the newline of the following line.

[Zoybean]

That's a good point, though I think it is the intentional behaviour of t and T, that if moving to the next instance of a character would not move at all, then it instead moves past that character, to the next instance.

[peter9477]

That's a good point, though I think it is the intentional behaviour of t and T, that if moving to the next instance of a character would not move at all, then it instead moves past that character, to the next instance.

You are correct. I'd reported it as an apparent bug in #4065 but after clarification I agree it's working as intended and is self-consistent (if a little hard to wrap one's brain around, for some of us ;-) ).

[rcorre]

EDIT: By the way, you can already get the proposed behavior today with this remap:

[keys.normal]
g = { l = ["select_mode", "goto_line_end", "normal_mode"] }

This doesn't always work as you'd expect, for the same reasons that v3w is not equivalent to treating 3w as a single motion: #1570 (comment)

Similarly, extend_to_line_end does not always do what I might expect: #1215 (reply in thread) (I wonder if that's a bug though?)

As noted in #1630 (comment), t<cr> also has some limitations, as it won't work on the first line, or the last if the file doesn't end with a newline.

For now, I think these bindings have more consistent behavior with other movement commands, but I'd also expect this to be default behavior:

l = ["collapse_selection", "extend_to_line_end"]
h = ["collapse_selection", "extend_to_line_start"]
s = ["collapse_selection", "select_mode", "goto_first_nonwhitespace", "exit_select_mode"]