Proposal: Selection groups

[nik-rev]

Selection groups will let you split your selections into groups. Commands that act on selections will be repeated for each group.

Example use case: Say you have this file and every letter is selected (6 selections, each represented by [...]):

[a] [b]
[c] [d]
[e] [f]

You want to rotate the contents of each line so the 1st selection on each line is swapped with the 2nd. It will become like this:

[b] [a]
[d] [c]
[f] [e]

Right now, to do this you need macros. So for this case, with the cursor on the first line you would do QxS <A-)><down>Qqq

But I think there's a more natural way of expressing this action, and that is with selection groups.

A selection group is a sequence of consecutive selections. All selection-based commands like A-) (rotate selection contents) always act on a single group.

This means we do not need to add any new commands for working with selection groups. Instead, every existing command will be repeated for each selection group. I represent each group {{...}} and there is always at least 1 group, just like there is always at least 1 selection. The above initial example will have just 1 group:

{{[a] [b]
[c] [d]
[e] [f]}}

Say we add a new command that creates a selection group on each line (similar in spirit to A-s) bound to the hypothetical placeholder keybinding A-β:

Using that will then create 3 selection groups, one on each line:

{{[a] [b]}}
{{[c] [d]}}
{{[e] [f]}}

Now, using A-) will execute the action for every selection group. So A-β + A-) will give you this file:

{{[b] [a]}}
{{[d] [c]}}
{{[f] [e]}}

With selection groups, we can replace QxS <A-)><down>Qqq with <A-β><A-)>, which is much easier to think about and makes editing text in Helix much more natural. You would have to reach for macros a lot less.

This is a large proposal, and will require lots of discussion. Some things to think about:

• How to introduce selection groups in a way that integrates well with the rest of the editing model?
• What should be the visual indicator for them?
• What commands make sense to add for selection groups?

---

thanks @rockboynton for the inspiration

[rockboynton]

Thanks for putting this proposal together! I think it will be a great addition to Helix

• What should be the visual indicator for them?

I personally don't think there needs to be a visual indicator beyond something in the status line saying how many groups you have and out of those, which one is your primary, similar to how we now have n/m sels. I.e we could also have n/m groups

[nik-rev]

Thanks for putting this proposal together! I think it will be a great addition to Helix

• What should be the visual indicator for them?

I personally don't think there needs to be a visual indicator beyond something in the status line saying how many groups you have and out of those, which one is your primary, similar to how we now have n/m sels. I.e we could also have n/m groups

We probably don't need a visual indicator for the currently active group, but even if you know that you have 3 groups: how do you know where each group starts and ends? There would have to be some way to tell. Groups can start and end at arbtirary positions, they are not limited to being line-wise

{{[a]}} [b]
{{[c] [d]
[e] [f]}}

[senekor]

What commands make sense to add for selection groups?

While the proposal sounds interesting, this question is why I'm sceptical about it. The only proposed command so far is to group selections by line, which is just the most trivial of use case. I feel like a simple model for managing the groups would feel restricted, incomplete and add more inconsistency to Helix' editing model that what it's worth. Making selection group management very flexible could get very complicated very quickly.

Nevertheless, I'll try to throw around some constructive ideas.

• If you already have N selections, you could select sub-parts of those selections the same way you would with s and get sub-selections where the previous N selections are promoted to selection groups.
• It could be nice if there was an equivalent of select_all_siblings that automatically puts siblings into selection groups. Say you have a list of lists... select one node in each list... then do select_all_siblings and you can reorder the list elements the same way for all lists at once.
• In general, any command that turns N selections into NxM selections could potentially make sense to generate selection groups. I don't think duplicating the commands would be a good idea and neither is making the grouping behavior the default. Maybe there could be a new grouped-selection mode that can be toggled manually and that switches the behavior of all these commands?
• What happens if you already have a bunch of selection groups and perform an operation that usually creates selection groups? Are the old and new groups flattened or can you end up with an arbitrarily deep tree of selection groups?

I'm not hugely in favor or against, but in my view using macros for these purposes is an appropriate amount of complexity.

[senekor]

Oh another thought. In the original example, selections were reordered by line:

a b   ->   b a
c d   ->   d c
e f   ->   f e

What if instead, one wanted to reorder by "colum"?

a b   ->   e f
c d   ->   a b
e f   ->   c d

If selection groups existed, I could see myself wanting to transpose them.