unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Duncan Findlay <duncf@google.com>
Cc: emacs-devel@gnu.org
Subject: Re: Set X primary selection with Emacs in xterm
Date: Fri, 03 Jun 2022 09:57:06 +0300	[thread overview]
Message-ID: <83y1yecjzx.fsf@gnu.org> (raw)
In-Reply-To: <CAPANw+MJ_wKTkSLXQOWMptEi1qiMWMKWXEyhTE_VbGBbik+YcQ@mail.gmail.com> (message from Duncan Findlay on Thu, 2 Jun 2022 21:03:49 -0700)

> 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.



  parent reply	other threads:[~2022-06-03  6:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-03  4:03 Set X primary selection with Emacs in xterm Duncan Findlay
2022-06-03  5:33 ` Po Lu
2022-06-03 12:27   ` Stefan Monnier
2022-06-10  6:36   ` Duncan Findlay
2022-06-03  6:57 ` Eli Zaretskii [this message]
2022-06-10 18:10   ` Duncan Findlay
2022-06-10 19:38     ` Eli Zaretskii
2022-06-11  2:03       ` Duncan Findlay
2022-06-03  9:55 ` Jean Louis
2022-06-10  5:49   ` Duncan Findlay
2022-06-10  8:50     ` James Cloos
2022-06-11  6:56     ` Jean Louis
2022-06-15  2:43       ` Duncan Findlay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83y1yecjzx.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=duncf@google.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).