paste multiple selections at once - #15199

Reawakening of #4694 by @stonewareslord

Say you have this text file, where {/} denotes a selection's head/cursor, and [/] denotes a selection's anchor/not-cursor.

here is [some} text
with selection [inside} of them
so [that} the example can be made better

If you yank, keep_primary_selection, and try to paste somewhere, only some will get pasted.

With the new paste_before_all and paste_after_all commands, some, inside, and that will all get pasted.

So let's open a scratch buffer and try to paste_before_all

[some}
[inside}
[that}

Note that your selection ranges are retained. Unlike in the #13600 pr by @nik-rev, that merges the selections into one, which is like... what's even the point?

Retaining the selection ranges lets the feature handle mulitline selections correctly. Let's say I wanted to yank multiple selections, to then join them with commas in a scratch buffer.

here is [some text
with} selection [inside} of them
so [that} the example can be made better

If the pastation was merged, I'd be in a bit of a pickle:

[some text
with
inside
that}

If I want to end up with some text with, inside, that, I can't naively split_selection_on_newline — I would then end up adding a comma after some text. I can remove that specific selection to avoid the problem, but it becomes a bit of a massive pain once you scale up the example.

But if the selection ranges are retained, now there's no issue:

[some text
with}
[inside}
[that}

I can remove_primary_selection on the last selection, then a,,

[some text
with,}
[inside,}
that

And then join_selections_space the entire buffer.

some text with, inside, that

I hope you get my point: retaining selections' ranges makes it a lot easier to multiact on them, once you paste_all them.
Helix is very good at caring about ranges more than lines, and the paste all feature should act no different.

As for why paste_before_all doesn't result in this:

[some text
with}[inside}[that}

That is because helix will collapse the multiple selections into one, if you do a. Curiously, it won't do it with i.
The selections need to be separated with something to fight against helix's selection merging behavior, and I thought that a newline is a pretty reasonable choice. Note that this joining newline is not included in your selections, so you won't need to trim_selections first or anything of that nature.

join_selections_space plays pretty well with selections pasted this way, even if you make a paste in the middle of some line, rather than a blank line. You can first paste_before_all, do the transformations you might wanna do on the selections, then if you wanted to join them with spaces rather than newlines, you just join_selections_space and you're done. Surprisingly less edgecasey than I thought it would be.

Since the code is mostly by @stonewareslord, I set them as the author of the commit. Because it was a massive pain to update their pr on latest master, I added myself as a co-author :p