"Copy selection on <object>" motion

[carrascomj]

In #1999, it was discussed how tree-sitter motions do not respect extend mode. The issue also brought up the desire to be able to copy selection on tree sitter objects (like C does for copy selection on next line). For instance, the user may want to copy the selection (create a new cursor) on the next argument:

I think there are different alternatives to solve this kind of movement:

1. A new mode that instead of extending selection, like extend mode v, copies the new selections. If this mode was V in the example above, it would be V]a to select the next argument.
2. A composition that requires a new command to create a new selection, then control only that selection and select the argument (Tree-sitter movements do not respect extend mode #1999 (comment)). This would require duplicate cursor+select only new cursor+]amia to reproduce the example.
3. A new motion that is copy selection on <object>, which can be used while being in other modes. This would require the same keystrokes as (1) if V is assigned to this motion.

I prefer (3) over (1)

I believe that a motion makes the most sense because it can be used in other modes. This allows for chains like vV]f that would not only extend the selection to the next function (v]f) but also select that entire function in the process. Note that neither of those behaviors are covered by extend mode at the moment. I think this kind of composition feels very natural.

The case against (2)

Being able to control just one cursor is nice (#943) but it creates an extra complexity that "copy selection on next/prev arg/function/whatever" should not require in my opinion (although it may be great for other cases). Of course, this only matters if the users actually find themselves trying to do something like in the example..

The case against (3)

It feels like a verb + object action, which is not what helix tries to do.

[the-mikedavis]

I'm not sure this is a good idea but I think you could approach this with the jumplist as well. Say we had a command that acted like C-o but retained the current primary and secondary selections, merging the selections from the entry in the prior jumplist if possible (not across buffers). You could select a function with ]f, save the selection in the jumplist with C-s, jump to the next function with ]f and merge the old selection in as a secondary selection (say it would be C-m or something like that).

[carrascomj]

This makes sense to me. It is easy to understand and quite flexible. There are 2 drawbacks I can see:

1. Less direct, it requires a bit more of "working memory" from the users, since they have to go back and forth and remember more things.
2. Do you lose the selections? I am not sure if the jumplist stores selections or only positions. Anyways, the selection motions are powerful enough in helix to make this not-a-problem.

I have implemented harcoded commands of copy selection on arg/function/class, without doing anything smart, and this jumplist seems like it'd be easier to implement (or less tedious).

[carrascomj]

I have checked that jumplist stores selections so I think this is very useful.

[EpocSquadron]

In kakoune, there are keybinds for combining marks, which are really just saved selections. We don't have marks yet, but its implementation could address your need as well.

[carrascomj]

I'll give a check to kakoune marks, thanks!

[the-mikedavis]

Ah TIL about kakoune marks 😄

I'll have to try them out a bit more but I think marks may be a more general solution to this than my suggestion.