Kitty: OSC 52 handler appends to clipboard instead of setting it

[PhilSwift7]

not sure if this is intended but if you run this code twice:

printf "\033]52;c;$(printf "%s" "test" | base64)\a"

your clipboard content will be testtest instead of test.

it can be fixed replacing += for = on the line 403 https://github.com/kovidgoyal/kitty/blob/master/kitty/window.py#L403

as a workaround running printf "\033]52;c;$(printf "%s" "" | base64)\a" clears the buffer but I don't know if that should be needed.

[kovidgoyal]

It is by design. See https://sw.kovidgoyal.net/kitty/protocol-extensions.html#pasting-to-clipboard

[agriffis]

@kovidgoyal I appreciate the extra functionality this provides. Would you consider making it configurable though? It violates the principle of least surprise, and becomes problematic when the user doesn't have the ability to send invalid codes to the terminal. For example I'm using mosh which supports OSC 52 pass-through, but since mosh is itself a terminal emulator in a sense, it doesn't permit a non-conforming payload.

[kovidgoyal]

Why not just get mosh to output the invalid sequences as well, they do no harm on any other terminal emulator.

[Luflosi]

Mosh does not seem to have active development right now, the latest release is from 22 Jul 2017. And people asking what's going on in https://github.com/mobile-shell/mosh/issues/974 and https://github.com/mobile-shell/mosh/issues/1021 don't make that look any better. So I'm afraid changing mosh is not a valid option at the moment.
I'm not saying that you should make this behaviour configurable, I'm just saying that your solution isn't practical for the foreseeable future.

[kovidgoyal]

Considering that mosh is used to log securely into remote systems (as a
replacement for ssh), if it is actually un-maintained, I would not feel
comfortable using it at all, let alone for OSC 52.

[agriffis]

I'm less interested in the mosh angle than the principle of least surprise. The current implementation of OSC 52 in kitty does something that's different from what users expect. I wonder if there would be a better way to approach it, to get the best of both worlds. For example, rather than requiring an invalid payload to clear the clipboard, instead support a specific invalid payload to explicitly concatenate. Then the default would be what people expect, but you could still get concatenation (which is quite a nice idea)

[vphantom]

For what it's worth, I don't use Mosh (it interfered with too many things I tried to do) but I do use the clipboard extensively. My solution was to simply fork a personal copy of Kitty with the += changed to = to get the expected behavior. The joy of open source. ;)

I don't speak much Python, but I bet I could make it into a new backwards-compatible flag in the clipboard_control configuration directive, if @kovidgoyal would consider that pull request.

[kovidgoyal]

On Thu, Feb 28, 2019 at 05:28:23PM -0800, Aron Griffis wrote:

I'm less interested in the mosh angle than the principle of least surprise. The current implementation of OSC 52 in kitty does something that's different from what users expect. I wonder if there would be a better way to approach it, to get the best of both worlds. For example, rather than requiring an invalid payload to clear the clipboard, instead support a specific invalid payload to explicitly concatenate. Then the default would be what people expect, but you could still get concatenation (which is quite a nice idea)

It's not users that expect this behavior, it is software. And software
can be changed to adopt a clearly better design, given that it was
carefully designed to make sure it degrades with no downside on terminal
emulators that don't support it.

While I could certainly change it to have a "concatenate" sequence
instead, I don't want to do that because it means yet another piece of
internal state the terminal emulator has to maintain. Remember that
applications can crash/networks go down leaving the terminal emulator
in an unexpected state, for the next application. Therefore, I try
to not have state in new protocols wherever possible.

[agriffis]

While I could certainly change it to have a "concatenate" sequence instead, I don't want to do that because it means yet another piece of internal state the terminal emulator has to maintain.

That is a good point, but it makes me think that for concatenation you could prefix the base64 payload with a bang.

printf $'\e]52;c;%s\a' 'aGk=' > /dev/tty   # reset clipboard to "hi"
printf $'\e]52;c;!%s\a' 'IHRoZXJl' >/dev/tty  # append so clipboard is "hi there"

This would seem to have similar benefits the current approach without changing the default behavior of OSC 52. It also avoids needing a configurable flag (although if it can't be solved another way, I would be happy to be able to configure it)

[kovidgoyal]

But prefixing the base64 string would make the sequence invalid on all other terminal emulators. Software would then need to detect it was running on kitty and modify its output accordingly. Right now all it needs to do is modify its output unconditionally and it will work on all terminal emulators.