Open Lenbok opened 2 years ago
architecturally speaking, this one is a bit tricky: reading the clipboard is an asynchronous operation that results in IPC on a number of operating systems, so care will need to be taken to initiate the request and receive the results without blocking the process on the clipboard response.
I just wanted to say, that you are not alone and that I would like to see this feature as well.
architecturally speaking, this one is a bit tricky: reading the clipboard is an asynchronous operation that results in IPC on a number of operating systems, so care will need to be taken to initiate the request and receive the results without blocking the process on the clipboard response.
Usually, software waits for about a second for such a response. I think it is an idea to configure this timeout via settings too.
The issue isn't with waiting, it's with waiting without blocking up the process and making it unresponsive
But when process asks terminal for clipboard contents, then it is probably ready for such a situation
Is your feature request related to a problem? Please describe.
Wezterm supports writing to the clipboard via OSC 52 sequence, but does not implement reading the clipbiard. Since this could be a risky feature to enable by default, it should be opt-in, which is what kitty and xterm do.
Describe the solution you'd like
A config setting should enable OSC 52 clipboard reading. Then applications can request the clipboard contents. In my case I have bash integration that connects readline copy bindings to write to the system clipboard, and I would like to also connect readline paste commands the same way.
Describe alternatives you've considered
I have had this readline integration working using xclip, but the OSC approach means it would also work in situations where X forwarding is not enabled. (I don't know if the wezterm ssh domain + multiplexer allows X forwarding and updating the DISPLAY variable inside the multiplexer when reattaching).