emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Set X primary selection with Emacs in xterm


From: Eli Zaretskii
Subject: Re: Set X primary selection with Emacs in xterm
Date: Fri, 03 Jun 2022 09:57:06 +0300

> From: Duncan Findlay <duncf@google.com>
> Date: Thu, 2 Jun 2022 21:03:49 -0700
> 
> I've attached a patch below to replace the `window-system' check with
> `display-selections-p', as that's documented as the preferred way to
> do this type of check. It also moves the check to lisp where we can
> advise it.

Thanks.  I think we should solve this differently.  I don't think it's
a good idea to call arbitrary Lisp from input-processing loop in
keyboard.c, anymore than we already do (which is already too much,
IMNSHO), especially if we envision advices for that code.

We should instead modify the condition in command_loop_1 to support
terminals that can set GUI selections.  terminal-parameter is a
primitive written in C, so command_loop_1 could call it directly (it
should also pay attention to the defcustom described below).

> The second patch changes  `(display-selections-p)' to return true
> under xterm with the setSelection feature enabled.

This part is mostly fine, but it should be augmented to resolve the
issues below.

> I don't know if this second patch can be submitted as is. It may break
> existing users. tmux, for example, removes the selection indicator
> from OSC 52 codes, so if emacs writes to both CLIPBOARD and PRIMARY
> selections, both updates will go to the same buffer on the user's
> side. I've filed https://github.com/tmux/tmux/issues/3192 with tmux. I
> haven't tested GNU screen.
> 
> This patch will also lead to extra data being sent to the user's
> terminal which they may not need or want. It might be wise to only
> send OSC 52 codes for primary selection if the user actually has a
> primary selection buffer, but I'm not sure the best way to do that.
> I'd appreciate some guidance here, or if somebody more experienced
> wants to take this on, that'd be most appreciated.

I think TRT here is to provide a defcustom, so that users could
disable this feature if it causes more trouble than it's worth.  With
time, perhaps we will collect enough user experience to come up with
the default value that makes the most sense on most supported systems;
for now setting the X selection could just be disabled by default.

> --- a/lisp/frame.el
> +++ b/lisp/frame.el
> @@ -2164,6 +2164,9 @@ display-selections-p
>         (not (null dos-windows-version))))
>       ((memq frame-type '(x w32 ns pgtk))
>        t)
> +     ((and (memq frame-type '(t))
> +           (eq (terminal-parameter nil 'xterm--set-selection) t))
> +      t)

This is unnecessarily strict: there should be no need to test
frame-type, since any frame type could arrange for this parameter when
it supports selections.

Thanks.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]