Osc 52 clipboard types #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.