Multi cursor kill clipboard integration bug

[MartyGentillon]

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

[MartyGentillon]

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.

[canoeberry]

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.

[canoeberry]

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 ...

[canoeberry]

I have implemented locally the following behavior.

1. 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.
2. 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?

[MartyGentillon]

I think it makes more sense to yank all kill rings combined with a newline character.

…

On Fri, Apr 21, 2017 at 3:19 AM, Jonathan Payne ***@***.***> wrote: I have implemented locally the following behavior. 1. 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. 2. 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? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#176 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQBZlKf1nk8UzxWwiFDgT08RI10hm3sks5ryIKdgaJpZM4NDwG8> .

[canoeberry]

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?

[MartyGentillon]

I agree, keeping the multiple regions in the kill rings is a huge feature. Look forward to seeing it.

…

On Sat, Apr 22, 2017 at 5:22 AM, Jonathan Payne ***@***.***> wrote: 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? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#176 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQBZgMWM9hfeYdnPlgHRxjMgnZ-TwYKks5ryfD1gaJpZM4NDwG8> .