Set X primary selection with Emacs in xterm

Set X primary selection with Emacs in xterm

[Duncan Findlay]

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

I frequently use Emacs over ssh and I'd really like to get both
primary and clipboard selections to work as close as possible to
running Emacs on X natively. I'd like to kill text in Emacs and have
that show up in my system clipboard so I can paste into other
applications. Similarly, if I select text with mark and keyboard (or
mouse with xterm-mouse-mode), I'd like it to update my local X's
primary selection so I can middle-click to paste it elsewhere. I have
two patches attached that got this working for me.

Without changes, with `(setq xterm-extra-capabilities
'(setSelection))', when I kill text, Emacs generates OSC 52 terminal
escape codes and xterm updates my clipboard. This works great! Emacs
also has support for updating the primary selection with this same
mechanism, e.g. `(gui-set-selection 'PRIMARY "primary")'. This, too,
works fine with xterm.

The bit that's missing is that when I select text with keyboard or
mouse (with xterm-mouse-mode), the primary selection is not updated.
It appears that the primary selection is only updated when
`(window-system)' is not nil.

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.

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

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.

Thanks
Duncan

[-- Attachment #2: 0001-Use-display-selections-p-when-deciding-to-update-pri.patch --]
[-- Type: text/x-patch, Size: 1470 bytes --]

From 5c7e11169b4043150a04623608de798e6edd821b Mon Sep 17 00:00:00 2001
From: Duncan Findlay <duncf@google.com>
Date: Fri, 20 May 2022 00:17:51 -0700
Subject: [PATCH 1/2] Use `display-selections-p' when deciding to update
 primary selection

`display-selections-p' is documented as the preferred way to determine
capabilities, over `window-system`.

This change moves the decision into lisp, where users can advise
changes.

 * src/keyboard.c (command_loop_1): Replace call to `window-system'
 with `display-selections-p' when deciding whether to update primary
 selection.
---
 src/keyboard.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/keyboard.c b/src/keyboard.c
index 274c7b3fa8..fd44a1a739 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -1577,7 +1577,7 @@ command_loop_1 (void)
 	    {
 	      /* Even if not deactivating the mark, set PRIMARY if
 		 `select-active-regions' is non-nil.  */
-	      if (!NILP (Fwindow_system (Qnil))
+	      if (!NILP (call0 (Qdisplay_selections_p))
 		  /* Even if mark_active is non-nil, the actual buffer
 		     marker may not have been set yet (Bug#7044).  */
 		  && XMARKER (BVAR (current_buffer, mark))->buffer
@@ -12154,6 +12154,7 @@ syms_of_keyboard (void)
 
   DEFSYM (Qpolling_period, "polling-period");
 
+  DEFSYM (Qdisplay_selections_p, "display-selections-p");
   DEFSYM (Qgui_set_selection, "gui-set-selection");
 
   /* The primary selection.  */
-- 
2.36.1.255.ge46751e96f-goog


[-- Attachment #3: 0002-Support-setting-primary-selection-with-xterm-setSele.patch --]
[-- Type: text/x-patch, Size: 930 bytes --]

From 9c2ffc771838765ec9f6b1621ec9c05617668aee Mon Sep 17 00:00:00 2001
From: Duncan Findlay <duncf@google.com>
Date: Thu, 2 Jun 2022 20:23:44 -0700
Subject: [PATCH 2/2] Support setting primary selection with xterm setSelection
 mode.

This will cause the xterm user's X primary selection buffer to be
updated when a selection is made in Emacs.

 * lisp/frame.el (display-selections-p): Return `t' when xterm's
 setSelection mode is enabled.
---
 lisp/frame.el | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lisp/frame.el b/lisp/frame.el
index 27f99fb7d2..eb8ae1c27d 100644
--- 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)
      (t
       nil))))
 
-- 
2.36.1.255.ge46751e96f-goog

Re: Set X primary selection with Emacs in xterm

[Po Lu]

(Patches should ideally be sent to bug-gnu-emacs@gnu.org, and not
here.)

Duncan Findlay <duncf@google.com> writes:

> I frequently use Emacs over ssh and I'd really like to get both
> primary and clipboard selections to work as close as possible to
> running Emacs on X natively. I'd like to kill text in Emacs and have
> that show up in my system clipboard so I can paste into other
> applications. Similarly, if I select text with mark and keyboard (or
> mouse with xterm-mouse-mode), I'd like it to update my local X's
> primary selection so I can middle-click to paste it elsewhere. I have
> two patches attached that got this working for me.
>
> Without changes, with `(setq xterm-extra-capabilities
> '(setSelection))', when I kill text, Emacs generates OSC 52 terminal
> escape codes and xterm updates my clipboard. This works great! Emacs
> also has support for updating the primary selection with this same
> mechanism, e.g. `(gui-set-selection 'PRIMARY "primary")'. This, too,
> works fine with xterm.
>
> The bit that's missing is that when I select text with keyboard or
> mouse (with xterm-mouse-mode), the primary selection is not updated.
> It appears that the primary selection is only updated when
> `(window-system)' is not nil.
>
> 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.
>
> The second patch changes  `(display-selections-p)' to return true
> under xterm with the setSelection feature enabled.

Thanks.  That mostly looks good to me, some minor comments below:

>  * src/keyboard.c (command_loop_1): Replace call to `window-system'
>  with `display-selections-p' when deciding whether to update primary
>  selection.

>  * lisp/frame.el (display-selections-p): Return `t' when xterm's
>  setSelection mode is enabled.

We don't indent each line of a ChangeLog entry to line up with the
asterisk, so this should be written:

 * src/keyboard.c (command_loop_1): Replace call to
`window-system' with `display-selections-p' when deciding
whether to update primary selection.

instead.  Please also make sure that each line of the commit message
takes no more than 64 columns on-screen.

>  lisp/frame.el | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/lisp/frame.el b/lisp/frame.el
> index 27f99fb7d2..eb8ae1c27d 100644
> --- 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))

This `memq' is redundant: why not (eq frame-type t) instead?

> +           (eq (terminal-parameter nil 'xterm--set-selection) t))
> +      t)

This doesn't look very clean... I wonder if there is a cleaner way to
check for this support.

Also, have you signed copyright papers?  And if not, how many lines of
code have you previously contributed to Emacs?

Re: Set X primary selection with Emacs in xterm

[Stefan Monnier]

>> --- 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 doesn't look very clean... I wonder if there is a cleaner way to
> check for this support.

This snippet should belong in `xt-mouse.el` instead, indeed.
Either using an advice, or a generic function, or a `<foo>-predicate`
variable, or by having `xt-mouse.el` set a "generic" frame parameter
which could be called `display-selection-p`.


        Stefan

Re: Set X primary selection with Emacs in xterm

[Duncan Findlay]

Thanks for the feedback!

On Thu, Jun 2, 2022 at 10:34 PM Po Lu <luangruo@yahoo.com> wrote:
>
> (Patches should ideally be sent to bug-gnu-emacs@gnu.org, and not
> here.)

I've sent a new version to the bug tracker:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55883

> Duncan Findlay <duncf@google.com> writes:
>
> > I frequently use Emacs over ssh and I'd really like to get both
> > primary and clipboard selections to work as close as possible to
> > running Emacs on X natively. I'd like to kill text in Emacs and have
> > that show up in my system clipboard so I can paste into other
> > applications. Similarly, if I select text with mark and keyboard (or
> > mouse with xterm-mouse-mode), I'd like it to update my local X's
> > primary selection so I can middle-click to paste it elsewhere. I have
> > two patches attached that got this working for me.
> >
> > Without changes, with `(setq xterm-extra-capabilities
> > '(setSelection))', when I kill text, Emacs generates OSC 52 terminal
> > escape codes and xterm updates my clipboard. This works great! Emacs
> > also has support for updating the primary selection with this same
> > mechanism, e.g. `(gui-set-selection 'PRIMARY "primary")'. This, too,
> > works fine with xterm.
> >
> > The bit that's missing is that when I select text with keyboard or
> > mouse (with xterm-mouse-mode), the primary selection is not updated.
> > It appears that the primary selection is only updated when
> > `(window-system)' is not nil.
> >
> > 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.
> >
> > The second patch changes  `(display-selections-p)' to return true
> > under xterm with the setSelection feature enabled.
>
> Thanks.  That mostly looks good to me, some minor comments below:
>
> >  * src/keyboard.c (command_loop_1): Replace call to `window-system'
> >  with `display-selections-p' when deciding whether to update primary
> >  selection.
>
> >  * lisp/frame.el (display-selections-p): Return `t' when xterm's
> >  setSelection mode is enabled.
>
> We don't indent each line of a ChangeLog entry to line up with the
> asterisk, so this should be written:
>
>  * src/keyboard.c (command_loop_1): Replace call to
> `window-system' with `display-selections-p' when deciding
> whether to update primary selection.
>
> instead.  Please also make sure that each line of the commit message
> takes no more than 64 columns on-screen.

I'd missed reading CONTRIBUTE, where this is all documented. Thank you.

>
> >  lisp/frame.el | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/lisp/frame.el b/lisp/frame.el
> > index 27f99fb7d2..eb8ae1c27d 100644
> > --- 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))
>
> This `memq' is redundant: why not (eq frame-type t) instead?

Oops, thank you. (I'm very new to lisp and mostly pattern matching.)

>
> > +           (eq (terminal-parameter nil 'xterm--set-selection) t))
> > +      t)
>
> This doesn't look very clean... I wonder if there is a cleaner way to
> check for this support.

I figured folks would probably object to that. Based on the responses
here, and given that this is only needed for text-based terminals, I
think using a generically-named terminal parameter that can be set by
any other library makes the most sense.

> Also, have you signed copyright papers?  And if not, how many lines of
> code have you previously contributed to Emacs?

This should be covered by my employer's copyright paperwork on file.

Thanks
Duncan

Re: Set X primary selection with Emacs in xterm

[Eli Zaretskii]

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

Re: Set X primary selection with Emacs in xterm

[Duncan Findlay]

On Thu, Jun 2, 2022 at 11:56 PM Eli Zaretskii <eliz@gnu.org> wrote:

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

I considered this, but given that we're making the same decision in
lisp/simple.el (deactivate-mark) using display-selections-p, the
benefits of sharing an implementation seemed compelling.

I see your point about wanting to minimize lisp in the command loop.
Can we just port display-selections-p to C and use it from both
places, or will that break things?

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

FWIW, the tmux bug is now fixed.

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

My initial resistance to a defcustom was because this feature already
requires xterm support for setSelection, which is already somewhat
rare, and it's already controlled by `select-active-regions'. Without
a new defcustom, it can be turned off with:
(add-hook 'terminal-init-xterm-hook (lambda () (setq
select-active-regions nil)))

But I accept the feedback that this is not discoverable, and people
want to avoid surprises, so having a defcustom that's off by default
makes sense. I'll upload a new version of the patch to the tracker
shortly.

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

In practice, are there other frame types? Is it reasonable to set
terminal-parameter for other frame types?

Thanks
Duncan

Re: Set X primary selection with Emacs in xterm

[Eli Zaretskii]

> From: Duncan Findlay <duncf@google.com>
> Date: Fri, 10 Jun 2022 11:10:50 -0700
> Cc: emacs-devel@gnu.org
> 
> On Thu, Jun 2, 2022 at 11:56 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > 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).
> 
> I considered this, but given that we're making the same decision in
> lisp/simple.el (deactivate-mark) using display-selections-p, the
> benefits of sharing an implementation seemed compelling.

That's not what bothers me, as I explain above.  I don't want us to
call more Lisp from the loop that processes keyboard input, if that
can be avoided.  And in this case, it can be easily avoided.

> I see your point about wanting to minimize lisp in the command loop.
> Can we just port display-selections-p to C and use it from both
> places, or will that break things?

I see no need for doing that.  display-selections-p is okay in Lisp,
as it is called from Lisp programs.
> > 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.
> 
> My initial resistance to a defcustom was because this feature already
> requires xterm support for setSelection, which is already somewhat
> rare, and it's already controlled by `select-active-regions'. Without
> a new defcustom, it can be turned off with:
> (add-hook 'terminal-init-xterm-hook (lambda () (setq
> select-active-regions nil)))
> 
> But I accept the feedback that this is not discoverable, and people
> want to avoid surprises, so having a defcustom that's off by default
> makes sense. I'll upload a new version of the patch to the tracker
> shortly.

Thanks.

> > > +     ((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.
> 
> In practice, are there other frame types? Is it reasonable to set
> terminal-parameter for other frame types?

Maybe not today, but I'd like this code to be more future-proof.
There's no need to test for more things that are absolutely necessary,
and testing for the xterm--set-selection parameter is enough in this
case, isn't it?

Re: Set X primary selection with Emacs in xterm

[Duncan Findlay]

On Fri, Jun 10, 2022 at 12:38 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Duncan Findlay <duncf@google.com>
> > Date: Fri, 10 Jun 2022 11:10:50 -0700
> > Cc: emacs-devel@gnu.org
> >
> > On Thu, Jun 2, 2022 at 11:56 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > 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).
> >
> > I considered this, but given that we're making the same decision in
> > lisp/simple.el (deactivate-mark) using display-selections-p, the
> > benefits of sharing an implementation seemed compelling.
>
> That's not what bothers me, as I explain above.  I don't want us to
> call more Lisp from the loop that processes keyboard input, if that
> can be avoided.  And in this case, it can be easily avoided.
>
> > I see your point about wanting to minimize lisp in the command loop.
> > Can we just port display-selections-p to C and use it from both
> > places, or will that break things?
>
> I see no need for doing that.  display-selections-p is okay in Lisp,
> as it is called from Lisp programs.

Got it -- thanks. This ended up being not nearly as difficult as I'd feared.

> > > > +     ((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.
> >
> > In practice, are there other frame types? Is it reasonable to set
> > terminal-parameter for other frame types?
>
> Maybe not today, but I'd like this code to be more future-proof.
> There's no need to test for more things that are absolutely necessary,
> and testing for the xterm--set-selection parameter is enough in this
> case, isn't it?

I've sent a new version that addresses this, too.
https://debbugs.gnu.org/55883

Thanks for bearing with me on this.


Duncan

Re: Set X primary selection with Emacs in xterm

[Jean Louis]

* Duncan Findlay <duncf@google.com> [2022-06-03 08:24]:
> I frequently use Emacs over ssh and I'd really like to get both
> primary and clipboard selections to work as close as possible to
> running Emacs on X natively. I'd like to kill text in Emacs and have
> that show up in my system clipboard so I can paste into other
> applications.

I have these settings and it works for me exactly how you explained
above.

(setq select-enable-clipboard t)
(setq select-enable-primary t)

> Similarly, if I select text with mark and keyboard (or mouse with
> xterm-mouse-mode), I'd like it to update my local X's primary
> selection so I can middle-click to paste it elsewhere. I have two
> patches attached that got this working for me.

For me your explained situation works without patches. I have the
above settings. But I may miss something as you mention
xterm-mouse-mode which I am not even using it ever. On my side it
works. 

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Set X primary selection with Emacs in xterm

[Duncan Findlay]

On Mon, Jun 6, 2022 at 7:39 AM Jean Louis <bugs@gnu.support> wrote:
>
> * Duncan Findlay <duncf@google.com> [2022-06-03 08:24]:
> > I frequently use Emacs over ssh and I'd really like to get both
> > primary and clipboard selections to work as close as possible to
> > running Emacs on X natively. I'd like to kill text in Emacs and have
> > that show up in my system clipboard so I can paste into other
> > applications.
>
> I have these settings and it works for me exactly how you explained
> above.
>
> (setq select-enable-clipboard t)
> (setq select-enable-primary t)

As I understand it, this configuration will cause killed text to be
put in both your clipboard and primary selection buffers.

I suppose that technically meets the criteria I outlined above -- it
should work identically over ssh and on X natively, but it's not quite
what I meant.

> > Similarly, if I select text with mark and keyboard (or mouse with
> > xterm-mouse-mode), I'd like it to update my local X's primary
> > selection so I can middle-click to paste it elsewhere. I have two
> > patches attached that got this working for me.
>
> For me your explained situation works without patches. I have the
> above settings. But I may miss something as you mention
> xterm-mouse-mode which I am not even using it ever. On my side it
> works.

Sorry, I should have been more precise.

I would like the primary selection to be updated with the contents of
the region, as described here:
https://www.gnu.org/software/emacs/manual/html_node/emacs/Primary-Selection.html

This requires `select-active-regions' to be non-nil. Do you have this
set in your configuration?

Thanks
Duncan

Re: Set X primary selection with Emacs in xterm

[James Cloos]

>>>>> "DF" == Duncan Findlay <duncf@google.com> writes:

DF> I would like the primary selection to be updated with the contents of
DF> the region, as described here:
DF> https://www.gnu.org/software/emacs/manual/html_node/emacs/Primary-Selection.html

DF> This requires `select-active-regions' to be non-nil. Do you have this
DF> set in your configuration?

select-active-regions is an insufficient requirement.

there also needs to be a var to prevent it w/o affectig anything else.

it is a cool idea, and it will be great for those who want it.

but i'm not alone in hating when applications running in terminals screw
over the way primary/secondary/clipboard normally work in said terminals.

so kudos, but a var to enable it at all, independent of any need for
select-active-regions to be t, is required.  whether it defaults to t
or to nil is ok either way.  but it is needed.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: Set X primary selection with Emacs in xterm

[Jean Louis]

* Duncan Findlay <duncf@google.com> [2022-06-10 09:45]:
> On Mon, Jun 6, 2022 at 7:39 AM Jean Louis <bugs@gnu.support> wrote:
> >
> > * Duncan Findlay <duncf@google.com> [2022-06-03 08:24]:
> > > I frequently use Emacs over ssh and I'd really like to get both
> > > primary and clipboard selections to work as close as possible to
> > > running Emacs on X natively. I'd like to kill text in Emacs and have
> > > that show up in my system clipboard so I can paste into other
> > > applications.
> >
> > I have these settings and it works for me exactly how you explained
> > above.
> >
> > (setq select-enable-clipboard t)
> > (setq select-enable-primary t)
> 
> As I understand it, this configuration will cause killed text to be
> put in both your clipboard and primary selection buffers.
> 
> I suppose that technically meets the criteria I outlined above -- it
> should work identically over ssh and on X natively, but it's not quite
> what I meant.
> 
> > > Similarly, if I select text with mark and keyboard (or mouse with
> > > xterm-mouse-mode), I'd like it to update my local X's primary
> > > selection so I can middle-click to paste it elsewhere. I have two
> > > patches attached that got this working for me.
> >
> > For me your explained situation works without patches. I have the
> > above settings. But I may miss something as you mention
> > xterm-mouse-mode which I am not even using it ever. On my side it
> > works.
> 
> Sorry, I should have been more precise.
> 
> I would like the primary selection to be updated with the contents of
> the region, as described here:
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Primary-Selection.html
> 
> This requires `select-active-regions' to be non-nil. Do you have this
> set in your configuration?

Yes, it is T in my configuration.

When I select region, I can use second (among three) mouse button to
insert selection into XTerm.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Set X primary selection with Emacs in xterm

[Duncan Findlay]

On Sat, Jun 11, 2022 at 9:16 AM Jean Louis <bugs@gnu.support> wrote:
> > > > Similarly, if I select text with mark and keyboard (or mouse with
> > > > xterm-mouse-mode), I'd like it to update my local X's primary
> > > > selection so I can middle-click to paste it elsewhere. I have two
> > > > patches attached that got this working for me.
> > >
> > > For me your explained situation works without patches. I have the
> > > above settings. But I may miss something as you mention
> > > xterm-mouse-mode which I am not even using it ever. On my side it
> > > works.
> >
> > Sorry, I should have been more precise.
> >
> > I would like the primary selection to be updated with the contents of
> > the region, as described here:
> > https://www.gnu.org/software/emacs/manual/html_node/emacs/Primary-Selection.html
> >
> > This requires `select-active-regions' to be non-nil. Do you have this
> > set in your configuration?
>
> Yes, it is T in my configuration.
>
> When I select region, I can use second (among three) mouse button to
> insert selection into XTerm.

Oh, I think I see what you mean. With your configuration I can select
text in emacs with mouse and paste with mouse into emacs or other
programs, but this is handled entirely by xterm. AIUI emacs is not
made aware of the selection and has no control over this.

If I make an active region with the keyboard (e.g. C-SPC, C-p), the
text shows as highlighted in emacs, but it does not update my primary
selection buffer unless I kill it, and it cannot be pasted with the
middle mouse button until it's killed. (Text highlighted by emacs is a
different color than text highlighted by xterm with my current config;
I'm not sure if this is default.) My patch fixes this, though it's a
pretty minor issue IMO.

The bigger benefit of my patch comes with xterm-mouse-mode enabled. In
this mode, most mouse events are passed through to Emacs, and are not
handled by Xterm itself. Without my patch, selecting text with the
mouse highlights it, but it doesn't update the primary selection and
can't be pasted with middle click. With my patch, the selected text
can be pasted into other programs with middle click. Pasting from
primary selection back into Emacs with middle-click requires xterm
getSelection support (haven't tried this yet) or Shift-MiddleClick
(handled by XTerm itself), though this is unaffected by my change.

With `xterm-select-active-regions' set to nil (default), my patch will
have no effect.

Thanks
Duncan