Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Support additional OSC 52 clipboard types
The OSC 52 escape sequence supports specifying which X selection buffer place to the selection into. The protocol format is: \033]52;C;D\007 The C parameter determines the selection buffer. It consists of zero or more of the following characters: c: CLIPBOARD p: PRIMARY q: SECONDARY s: XTerm-selected (based on XTerm.vt100.selectToClipboard) 0-7: Numbered cut buffer The default if left blank is 's0', representing the configurable primary/clipboard selection and cut buffer 0. [1] D is the base64 encoded text to place in the selection buffer. This patch modifies the transferred clipboard data to include both the selection parameter and the base64 text. I.e. previously the transferred clipboard data only contained 'D', and now it contains 'C;D'. To test this functionality: 1. Open XTerm 2. Ctrl-Right Click and select 'Allow Window Ops' 3. Connect to a server w/ mosh 4. Run the following in the remote connection: $ printf "\033]52;c;$(echo test1234 | base64)\007" $ printf "\033]52;p;$(echo test2345 | base64)\007" $ printf "\033]52;q;$(echo test3456 | base64)\007" 6. Open another terminal on the local machine and run: $ xclip -o -selection clipboard test1234 $ xclip -o -selection primary test2345 $ xclip -o -selection secondary test3456 7. You can also try: $ printf "\033]52;;$(echo testdefault | base64)\007" (This should update either the clipboard or primary selection based on the Xterm settings) 8. To test the cut buffers you can use the same procedure, substituting the cut buffer number in C, and then use 'xcutsel' to transfer the data from the cut buffer to the PRIMARY selection, where it can then be viewed with 'xclip'. Note, I observed that XTerm does not currently (as of XTerm patch 358) support specifying more than one value in C. The specification does support it, and this appears to just be a simple bug in XTerm (a patch has been submitted to the maintainer to fix it). [1] https://github.com/ThomasDickey/xterm-snapshots/blob/master/ctlseqs.txt Fixes mobile-shell#967. Part 2 ====== Instead of using the contents of the clipboard to determine if the user has copied any text, use a sequence number that is updated whenever text is copied. Consider the following scenario (as described in mobile-shell#1090): 1. User copies text 'abc' on remote machine via mosh. 2. User copies text 'xyz' on local machine. 3. User copies text 'abc' on remote machine again. The local clipboard will still has 'xyz' because the most recent copy text 'abc' matches the last text copied via mosh, so it does not detect that the user copied new text and does not update the local clipboard. This patch updates detection of newly copied text via a sequence number. This number is an 8-bit unsigned integer that is updated every time new text is copied. This will roll over after 256 clipboard updates, but that is fine as we only care about it being different than the last value. Fixes mobile-shell#1090. Fixes mobile-shell#637.
- Loading branch information