Consistent extend_* move_* and goto_*

[eugenesvk]

• Move command move with deselection (of the previous object) then selection
• Extend commands move with selection
• Goto commands move with deselection (goto_line_end), but then some commands move with deselection then selection (goto_next_paragraph)

So you can't goto the end of a paragraph without selecting like you can goto line end

Would be nice if these were all consistent, and if you need to move to the end of a paragraph with deselection then selection, there should be a move_this_paragraph_end command

[perlinm]

This issue is possibly a duplicate (or at least a close cousin) of #3114, which also has some discussion of the (in)consistency of these commands (example).

Unfortunately, #3114, was closed as "not planned" 🙁. Maybe putting the inconsistency aspect front-and-center will make the maintainers reconsider.

At the moment, it's impossible to tell/predict behavior from the name of the move_*, goto_*, and extend_* commands. The only way to tell is to try it out (or inspect source code). This need not be the case.

Just to clarify: in my interpretation of this issue, Helix would not need to change any default behaviors. It would merely need to revise/rename key commands to be more consistent with their names, for example:

• goto_* could move without extending selection (that is, always resulting in a single-character selection at the location of the cursor)
• extend_* could move and extend the text selection
• move_* could have more custom/context-aware behavior for text selection, similarly to how to the current move_prev_word_start in normal mode will change (rather than extend) the current selection to the next word.

Default key mappings would then be adjusted to reflect the changes to the commands, presumably setting most defaults to move_* since it allows for more customized behavior.

[eugenesvk]

Yeah, this is only about the inconsistency of commands in the same "group". The design of Helix favors the "select first" (ask later ;) approach, so

Helix would not need to change any default behaviors

yes, the defaults can be whatever is most consistent with that design.

It's just that when you rebind a bunch of commands, these inconsistencies start to confuse you

more custom/context-aware behavior for text selection

Not sure I understand this. Could you give an example when move behaves differently? Does it not always deselects current selection and then starts a new selection from your current position to the end of the move position?

[perlinm]

Could you give an example when move behaves differently?

Not sure, to be honest. Perhaps always deselecting + starting a new selection is the way to go. I suppose one question is how these commands interact with normal vs. select mode, so I was thinking that move_* could depend on the mode. On second thought, maybe that's bad though, and maybe select mode should simply have all navigation commands set to their extend_* versions.

It's just that when you rebind a bunch of commands, these inconsistencies start to confuse you

💯% this. Due to these inconsistencies, I pretty much don't understand any of the text navigation section of my Helix config file, and probably never will unless this issue is fixed. It's very much a situation of "figure it out once, and hope you never have to touch it again".

[eugenesvk]

On second thought, maybe that's bad though, and maybe select mode should simply have all navigation commands set to their extend_* versions

I think the current system is better with the extend_* versions since it's not mode-dependent, so slightly easier to use in other modes without having to add mode on/off command wrappers and I like the explicit naming more

I pretty much don't understand any of the text navigation section of my Helix config file

Yeah, this and the word command name qualifiers (why does move_NEXT_word_end jump to the end of THIS word (the one under the cursor?)) confuses reading the nav config part, though I've added extensive comments/symbols to the config and a pic cheatsheet to make it easier to edit/understand

[perlinm]

why does move_NEXT_word_end jump to the end of THIS word

This one is easy to answer: the command should be read as "next [word end]", not "[next word] end" 🙂. That is, the next ending of a word, rather than the ending of the next word.

[eugenesvk]

It didn't help that prev/next word start/end movements don't end up on the same spot (though there is another issue opened for that)