Re: master 2b2fd39: xterm.el: Implement OSC-52 functionality for setting the X selection

Re: master 2b2fd39: xterm.el: Implement OSC-52 functionality for setting the X selection

[Glenn Morris]

This is not a small change, but I see no corresponding entry in copyright.list.

Stefan Monnier wrote:

> branch: master
> commit 2b2fd3965f8c096b39de7e0418d37433269a1dce
> Author: Philipp Stephani <p.stephani2@gmail.com>
> Commit: Stefan Monnier <monnier@iro.umontreal.ca>
>
>     xterm.el: Implement OSC-52 functionality for setting the X selection
>     
>     * lisp/term/xterm.el (xterm-max-cut-length): New var.
>     (xterm--set-selection, terminal-init-xterm-activate-set-selection): New funs.
>     (terminal-init-xterm, xterm--version-handler): Use them.
> ---
>  lisp/term/xterm.el |   93 +++++++++++++++++++++++++++++++++++++++++++++++++--
>  1 files changed, 89 insertions(+), 4 deletions(-)
>
> diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
> index 519f691..f4d1a84 100644
> --- a/lisp/term/xterm.el
> +++ b/lisp/term/xterm.el
> @@ -37,7 +37,8 @@ If a list, assume that the listed features are supported, without checking.
>  
>  The relevant features are:
>    modifyOtherKeys  -- if supported, more key bindings work (e.g., \"\\C-,\")
> -  reportBackground -- if supported, Xterm reports its background color"
> +  reportBackground -- if supported, Xterm reports its background color
> +  setSelection     -- if supported, Xterm saves yanked text to the X selection"
>    :version "24.1"
>    :group 'xterm
>    :type '(choice (const :tag "No" nil)
> @@ -45,7 +46,24 @@ The relevant features are:
>                   ;; NOTE: If you add entries here, make sure to update
>                   ;; `terminal-init-xterm' as well.
>                   (set (const :tag "modifyOtherKeys support" modifyOtherKeys)
> -                      (const :tag "report background" reportBackground))))
> +                      (const :tag "report background" reportBackground)
> +                      (const :tag "set X selection" setSelection))))
> +
> +(defcustom xterm-max-cut-length 100000
> +  "Maximum number of bytes to cut into xterm using the OSC 52 sequence.
> +
> +The OSC 52 sequence requires a terminator byte.  Some terminals will ignore or
> +mistreat a terminated sequence that is longer than a certain size, usually to
> +protect users from runaway sequences.
> +
> +This variable allows you to tweak the maximum number of bytes that will be sent
> +using the OSC 52 sequence.
> +
> +If you select a region larger than this size, it won't be copied to your system
> +clipboard.  Since clipboard data is base 64 encoded, the actual number of
> +string bytes that can be copied is 3/4 of this value."
> +  :group 'xterm
> +  :type 'integer)
>  
>  (defconst xterm-paste-ending-sequence "\e[201~"
>    "Characters send by the terminal to end a bracketed paste.")
> @@ -620,7 +638,13 @@ The relevant features are:
>          ;; introduced) or higher, initialize the
>          ;; modifyOtherKeys support.
>          (when (>= version 216)
> -          (terminal-init-xterm-modify-other-keys))))))
> +          (terminal-init-xterm-modify-other-keys))
> +        ;; In version 203 support for accessing the X selection was
> +        ;; added.  Hterm reports itself as version 256 and supports it
> +        ;; as well.  gnome-terminal doesn't and is excluded by this
> +        ;; test.
> +        (when (>= version 203)
> +          (terminal-init-xterm-activate-set-selection))))))
>  
>  (defun xterm--query (query handlers)
>    "Send QUERY string to the terminal and watch for a response.
> @@ -699,7 +723,10 @@ We run the first FUNCTION whose STRING matches the input events."
>                      '(("\e]11;" .  xterm--report-background-handler))))
>  
>      (when (memq 'modifyOtherKeys xterm-extra-capabilities)
> -      (terminal-init-xterm-modify-other-keys)))
> +      (terminal-init-xterm-modify-other-keys))
> +
> +    (when (memq 'setSelection xterm-extra-capabilities)
> +      (terminal-init-xterm-activate-set-selection)))
>  
>    ;; Unconditionally enable bracketed paste mode: terminals that don't
>    ;; support it just ignore the sequence.
> @@ -719,6 +746,64 @@ We run the first FUNCTION whose STRING matches the input events."
>    (push "\e[?2004l" (terminal-parameter nil 'tty-mode-reset-strings))
>    (push "\e[?2004h" (terminal-parameter nil 'tty-mode-set-strings)))
>  
> +(defun terminal-init-xterm-activate-set-selection ()
> +  "Terminal initialization for `gui-set-selection'."
> +  ;; All text terminals are represented by the nil GUI type.  We need
> +  ;; to detect XTerm again in `xterm--set-selection' using the
> +  ;; terminal parameters.
> +  (gui-method-define gui-set-selection nil #'xterm--set-selection))
> +
> +(defun xterm--set-selection (type data)
> +  "Copy DATA to the X selection using the OSC 52 escape sequence.
> +
> +TYPE specifies which selection to set; it must be either
> +`PRIMARY' or `CLIPBOARD'.  DATA must be a string.
> +
> +This can be used as a `gui-set-selection' method for
> +xterm-compatible terminal emulators.  Then your system clipboard
> +will be updated whenever you copy a region of text in Emacs.
> +
> +If the resulting OSC 52 sequence would be longer than
> +`xterm-max-cut-length', then the TEXT is not sent to the system
> +clipboard.
> +
> +This function either sends a raw OSC 52 sequence or wraps the OSC
> +52 in a Device Control String sequence.  This way, it will work
> +on a bare terminal emulators as well as inside the screen
> +program.  When inside the screen program, this function also
> +chops long DCS sequences into multiple smaller ones to avoid
> +hitting screen's max DCS length."
> +  (let* ((init-function (terminal-parameter nil 'terminal-initted))
> +         (xterm (eq init-function 'terminal-init-xterm))
> +         (screen (eq init-function 'terminal-init-screen)))
> +    ;; Only do something if the current terminal is actually an XTerm
> +    ;; or screen.
> +    (when (or xterm screen)
> +      (let* ((bytes (encode-coding-string data 'utf-8-unix))
> +             (base-64 (if screen
> +                          (replace-regexp-in-string
> +                           "\n" "\e\\\eP"
> +                           (base64-encode-string bytes)
> +                           :fixedcase :literal)
> +                        (base64-encode-string bytes :no-line-break)))
> +             (length (string-bytes base-64)))
> +        (if (> length xterm-max-cut-length)
> +            (progn
> +              (warn "Selection too long to send to terminal: %d bytes" length)
> +              (sit-for 2))
> +          (send-string-to-terminal
> +           (concat
> +            (when screen "\eP")
> +            "\e]52;"
> +            (cond
> +             ((eq type 'PRIMARY) "p")
> +             ((eq type 'CLIPBOARD) "c")
> +             (t (error "Invalid type %S" type)))
> +            ";"
> +            base-64
> +            "\a"
> +            (when screen "\e\\"))))))))
> +
>  ;; Set up colors, for those versions of xterm that support it.
>  (defvar xterm-standard-colors
>    ;; The names in the comments taken from XTerm-col.ad in the xterm
>
> _______________________________________________
> Emacs-diffs mailing list
> Emacs-diffs@gnu.org
> https://lists.gnu.org/mailman/listinfo/emacs-diffs

Re: master 2b2fd39: xterm.el: Implement OSC-52 functionality for setting the X selection

[Stefan Monnier]

> This is not a small change, but I see no corresponding entry in
> copyright.list.

AFAIK this was all written by Google employees and is covered by
Google's blanket assignment.  We don't have a good way to track/check
it, tho.


        Stefan

Re: master 2b2fd39: xterm.el: Implement OSC-52 functionality for setting the X selection

[Glenn Morris]

Stefan Monnier wrote:

> AFAIK this was all written by Google employees and is covered by
> Google's blanket assignment.

Ah right, I missed that.

>  We don't have a good way to track/check it, tho.

Indeed. I think I'm liable to forget this the next time it comes up.
A @gmail address doesn't make me think "employed by Google".

(I'm always somewhat surprised that we apparently don't need individuals
whose employer owns their stuff to sign something anyway.)

Re: master 2b2fd39: xterm.el: Implement OSC-52 functionality for setting the X selection

[Stefan Monnier]

>> AFAIK this was all written by Google employees and is covered by
>> Google's blanket assignment.
> Ah right, I missed that.

You're not alone: I forgot about it twice along the way.  And it took me
a little while after your question to remember what was the answer.

>> We don't have a good way to track/check it, tho.
> Indeed.  I think I'm liable to forget this the next time it comes up.

For me, it's not just "liable to".  I know for a fact that I will
have forgotten (probably by next week or so).

> A @gmail address doesn't make me think "employed by Google".

Indeed, that person should also have (and should use) a @google.com address.
Maybe recording the @google.com address would be a good first step to
try and keep track of this.

> (I'm always somewhat surprised that we apparently don't need individuals
> whose employer owns their stuff to sign something anyway.)

Same here.


        Stetfan

Re: master 2b2fd39: xterm.el: Implement OSC-52 functionality for setting the X selection

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> schrieb am So., 19. Apr. 2015 um
05:13 Uhr:

> >> AFAIK this was all written by Google employees and is covered by
> >> Google's blanket assignment.
> > Ah right, I missed that.
>
> You're not alone: I forgot about it twice along the way.  And it took me
> a little while after your question to remember what was the answer.
>
> >> We don't have a good way to track/check it, tho.
> > Indeed.  I think I'm liable to forget this the next time it comes up.
>
> For me, it's not just "liable to".  I know for a fact that I will
> have forgotten (probably by next week or so).
>
> > A @gmail address doesn't make me think "employed by Google".
>
> Indeed, that person should also have (and should use) a @google.com
> address.
> Maybe recording the @google.com address would be a good first step to
> try and keep track of this.
>

Please do use our @google.com addresses. I'm only using my private account
for convenience reasons.
If you want to validate the address send a quick mail there and I'll reply.

[-- Attachment #2: Type: text/html, Size: 1579 bytes --]

Re: master 2b2fd39: xterm.el: Implement OSC-52 functionality for setting the X selection

[Glenn Morris]

Stefan Monnier wrote:

>> (I'm always somewhat surprised that we apparently don't need individuals
>> whose employer owns their stuff to sign something anyway.)
>
> Same here.

For the record, assign@gnu confirmed to me that people covered by
employer agreements don't need to do individual assignments (unless they
want to cover themselves in case of future change of employment).

(Still seems weird to me, but there you go.)

Re: master 2b2fd39: xterm.el: Implement OSC-52 functionality for setting the X selection

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > For the record, assign@gnu confirmed to me that people covered by
  > employer agreements don't need to do individual assignments (unless they
  > want to cover themselves in case of future change of employment).

For a work made for hire, the copyright belongs to the employer
so the employer can assign it.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: master 2b2fd39: xterm.el: Implement OSC-52 functionality for setting the X selection

[Stephen J. Turnbull]

Richard Stallman writes:

 > For a work made for hire, the copyright belongs to the employer
 > so the employer can assign it.

And *only* the employer can assign it.  I think that may be part of
what's bothering Glenn -- I used to have a contract that said the
Japanese government and I are joint copyright holders in any works
produced on work time.  I'm not employed as a programmer so it's not
considered work for hire.  (I need to review that, the law has changed
and my employer was privatized -- and Japanese law effectively allows
them to change my contract terms at any time without my agreement.)

Re: master 2b2fd39: xterm.el: Implement OSC-52 functionality for setting the X selection

[Glenn Morris]

Richard Stallman wrote:

>   > For the record, assign@gnu confirmed to me that people covered by
>   > employer agreements don't need to do individual assignments (unless they
>   > want to cover themselves in case of future change of employment).
>
> For a work made for hire, the copyright belongs to the employer
> so the employer can assign it.

Right. The thing I find slightly odd is that we don't require people to
sign a statement that says "my contributions to GNU foo are a work for
hire, and are owned by Foocorp" (or equivalent). Apparently just saying
that in an email is ok, and no central record of such statements is kept.
I just find it an odd gap in the FSF record-keeping system.

Re: master 2b2fd39: xterm.el: Implement OSC-52 functionality for setting the X selection

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The thing I find slightly odd is that we don't require people to
  > sign a statement that says "my contributions to GNU foo are a work for
  > hire, and are owned by Foocorp" (or equivalent).

We're doing what lawyers advised us to do.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: master 2b2fd39: xterm.el: Implement OSC-52 functionality for setting the X selection

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> schrieb am Fr., 17. Apr. 2015 um
20:06 Uhr:

> > This is not a small change, but I see no corresponding entry in
> > copyright.list.
>
> AFAIK this was all written by Google employees and is covered by
> Google's blanket assignment.  We don't have a good way to track/check
> it, tho.
>
>
The current code was written by me (phst@google.com) and borrowed
from/inspired by Robert Ginda (rginda@google.com,
http://git.chromium.org/gitweb/?p=chromiumos/platform/assets.git;a=blob_plain;f=chromeapps/hterm/etc/osc52.el;hb=HEAD
).

[-- Attachment #2: Type: text/html, Size: 1070 bytes --]

Re: master 2b2fd39: xterm.el: Implement OSC-52 functionality for setting the X selection

[Stefan Monnier]

> The current code was written by me (phst@google.com) and borrowed
> from/inspired by Robert Ginda (rginda@google.com,
> http://git.chromium.org/gitweb/?p=chromiumos/platform/assets.git;a=blob_plain;f=chromeapps/hterm/etc/osc52.el;hb=HEAD
> ).

Thanks.  I reworked it to adapt to some changes that were done in
xterm.el in the mean time, and installed it into "master".
Note that this is only enabled if it is requested explicitly in
xterm-extra-capabilities because:
- I don't know how to reliably (and discretely) check that it works.
- If the xterm doesn't actually support it, enabling it causes a timeout
  (or a lost event) when you C-y.


        Stefan