Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Osc 52 clipboard types #1

Merged
merged 2 commits into from
Aug 19, 2023

Conversation

kkonevets
Copy link
Owner

No description provided.

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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants