Multi cursor kill clipboard integration bug
MartyGentillon opened this issue · 7 comments
When multi cursors support is enabled, and kill region is executed with the following selections (indicated with square brackets)
[test] [123]
The system clipboard should be updated with the two cut regions joined with new lines such as:
test
123
Just like it would be if I used Sublime Text's cut command. However, currently only the first cursor's region is sent to the system clipboard.
test
Using emacs pro essentials v3.1.4 sublime text b3126 windows 10 creators update
There is a related bug with yank. When I cut
test
123
from a web browser and then yank it with the following cursors
[] []
I get
test
123 test
123
rather than
test[] 123[]
which I get if I use the Sublime text paste command.
There are two separate but seemingly related issues here.
The first is, I really do keep the individual regions stored separately in each kill ring entry, unlike sublime. Sublime takes each region and concats them together using Newline but how does that work if the regions you're killing already contain Newline characters? Answer: it doesn't.
Therefore, I thought there was no point in combining all those regions into a single clipboard entry as well. One of the reasons for THAT decision is that whenever you press Yank I have to consult the clipboard to see if it's the same as the current kill ring entry and, if so, NOT copy it back into the kill ring. I thought that was "too hard" to do if I made the clipboard different from what was stored in Sublime (which it would be, because I store separate regions) but I suppose I could just compare as though the separate regions were joined with Newlines and make my decision that way.
Regarding your yank comment, I decided that if the number of regions in the kill ring was less than the number of cursors, I would duplicate the entries, and that's why you got what you got. Also, if there are more regions in the kill than cursors, it will just yank that many regions. I am not sure I want to go down the path of supporting unpredictable behavior, where depending on the number of newlines in the regions you have killed, you get different behavior.
I guess I should have said that I will definitely see if I can fix the first problem for you.
The second problem could possibly be fixed with a new command, yank-into-cursors, or something like that, where the entry is split at the newline character. But again, that feels quite hokey to me. Maybe it would only work if the current kill ring entry is a single region ...
I have implemented locally the following behavior.
- When you kill multiple regions, they are copied to the external clipboard as a single newline separated string. This is like the default sublime behavior.
- When you perform a yank-like operation (yank, yank-pop, yank-and-choose) it compares the clipboard to the current kill_ring entry as though the kill_ring entry were a single entry with newline characters separating them, rather than just looking at the first region.
I think it works well.
And now I am trying to decide whether a yank of multiple regions into a single cursor should just yank all the regions joined by a newline character. That is, if the current kill ring entry is multiple regions but the number of cursors is exactly 1, should I join the kill ring entry with newlines and yank a single entry or should I continue with the current behavior of yanking just the first region. And if the number of cursors is >= 2, I will continue the old behavior of yanking the first 2 regions into the first two cursors.
Thoughts?
So, with one cursor, yank everything with newlines. If multiple cursors, do what it currently does.
That's what I am going to go with and see how I like it.
I hope you agree that keeping proper individual regions in the kill ring is a huge feature. It allows all sorts of cool things that were not possible before.
I will get back when it's working. Are you up for testing it on a branch yourself?