If had a previous OSC-52 (paste) in MOSH and there’s a disconnect, blink does a spurious paste

[idvorkin]

Checklist

• Using latest version on the App Store
• Read the docs
• [] Searched for existing GitHub issues

Configuration

13.5.11.261

Describe the bug

If you did an OSC-52 (paste) in MOSH and there’s a disconnect, blink does a spurious paste. This can repro if you close/open blink (and I suspect if Blink was idle for a few minutes).

This is painful as it clears the system clipboard.

[idvorkin]

Ping

[idvorkin]

@carloscabanero - Any ETAs here? Anything I can do to help diagnose?

[carloscabanero]

Hi! So we have been discussing this one thoroughly over Discord (specially @rrgeorge). The problem is not what the issue is, but what the proper solution should look like. Mosh in this scenario is behaving the way it should.

One idea is to create a special mode where we identify when this situation may happen, and then try to skip certain sequences at the terminal level. This may even require a buffer due to the nature of OSC-52 so not easy, specially because we can only touch the client.

Another suggestion from @rrgeorge himself over Discord was to assign a special clipboard to the terminal, and use that as an exchange instead of the system clipboard:

I just had an idea, and I was wondering what the blink devs thought of it. When using OSC-52 over mosh, it creates a problem where every time the session is loaded, (changing tabs, return to blink, etc) the system clipboard is overwritten with whatever osc-52 was last sent from that session. It could be new, or it could be super old. It’s such a nuisance that I stopped using osc-52 in my sessions. But it’s such a useful thing if it worked in a more user friendly way. So onto my idea:
Instead of immediately losing and osc-52 sequence into the system clipboard, have a “terminal clipboard” unique to that terminal that can be displayed with keyboard shortcut that you can manually copy from. You can further that with having the contents auto selected, so you could do some thing like:
Cmd+C -> Display Clipboard, Cmd+C (again) copy it to the system clipboard

[idvorkin]

Happy to hop on discord. Can you tag me on the relevant threads.

[idvorkin]

Slightly related, I've been using a pipe to pbcopy/pbpaste solution on my Mac for similar use cases:

See #1672

[carloscabanero]

Another thing we are testing atm is to skip OSC52 after reconnection from our side, at least for a few seconds. Because we are the ones triggering the reconnection step, we may be able to control this sequence better at that stage. We need to check if this is possible.

[carloscabanero]

Alright, so we have a fix for this, but it comes with a small quirk (which is actually Mosh'). This happens in the desktop as well, you can try it out.

Mosh holds its own state of the clipboard, so even if that changes outside, copying the same sequence won't trigger it again. Ie. if you copy on Mosh, then copy somewhere else, and then copy the same sequence on Mosh, the last copy won't happen. This is because Mosh still thinks it has the proper Clipboard state, so it does not try to overwrite it.

I think this is a small quirk and probably no one will notice, but mentioning here so everyone can give their take.

For future reference, I think the only approach that may solve this is to actually have a different "Clipboard" for the terminal, as that could follow the state as-is. We are still figuring out what the mechanics for that would be, but definitely interesting.

[idvorkin]

That's fantastic news! Awesome work being persistent on this!

…

On Mon, May 15, 2023 at 4:50 PM carloscabanero ***@***.***> wrote: Alright, so we have a fix for this, but it comes with a small quirk (which is actually Mosh'). This happens in the desktop as well, you can try it out. Mosh holds its own state of the clipboard, so even if that changes outside, copying the same sequence won't trigger it again. Ie. if you copy on Mosh, then copy somewhere else, and then copy the same sequence on Mosh, the last copy won't happen. This is because Mosh still thinks it has the proper Clipboard state, so it does not try to overwrite it. I think this is a small quirk and probably no one will notice, but mentioning here so everyone can give their take. For future reference, I think the only approach that may solve this is to actually have a different "Clipboard" for the terminal, as that could follow the state as-is. We are still figuring out what the mechanics for that would be, but definitely interesting. — Reply to this email directly, view it on GitHub <#1205 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACETFNIW5NSQDJZ66576L3XGK6MHANCNFSM4X7A22DA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[carloscabanero]

This is now out on 16.1.8!