Add support for extend_file_{start,end}.

[hadronized]

Solves #11766.

[hadronized]

I allowed myself for a bit of refactoring — the From<Mode> for Movement, as the pattern is present in many places — but it’s optional, even though I think it still makes sense to do it now, as I needed to do it again too.

[pascalkuthe]

I think we generally want to move away from mode dependent keybindings. So in this case I would actually be ok with doing a breaking change and making the goto version of the command neber extend and changing the default select mode bindings to the extend version.

I am not sure about the refactor for that reason. Codewise looks fine but it's really a pattern that shouldn't be prevelant and will hopefully be gone at some point. So maybe we just kepe the code as is (less merge conflicts) since it's only temporary.

@the-mikedavis what do you think think

[hadronized]

and changing the default select mode bindings to the extend version.

I’m not sure what that means, may I ask you to explain?

[the-mikedavis]

A good example of what @pascalkuthe is describing is some of the existing bindings in select mode in the default keymap:

helix/helix-term/src/keymap/default.rs

Lines 338 to 341 in b18a471

	"h" | "left" => extend_char_left,
	"j" | "down" => extend_visual_line_down,
	"k" | "up" => extend_visual_line_up,
	"l" | "right" => extend_char_right,

Rather than "smart" commands that look at the mode and decide whether to move or extend we have the default keymap for normal mode use the move versions of the commands and the select mode default keybindings use the extend version.

So in this case we would add these extend_file_{start,end} to the select mode keymap and update the equivalent entries in the normal mode keymap to use ones that only move and do not look at mode

[hadronized]

Okay, that makes sense. So the refactoring I’m doing is probably not needed, since it’s what looks at the mode to deduce the movement?

[the-mikedavis]

Yeah exactly, eventually we shouldn't be converting Mode to Movement anywhere

[hadronized]

Okay, I’ll change the PR when I have some time, but am I correct assuming I should only do that for the commands I want to introduce and let the big refactoring to someone else / another PR?

Alternative question: what name should I use for the commands? I realized we sometimes use extend_* and sometimes extend_to_*.