unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Duncan Findlay <duncf@google.com>
To: Po Lu <luangruo@yahoo.com>
Cc: emacs-devel@gnu.org
Subject: Re: Set X primary selection with Emacs in xterm
Date: Thu, 9 Jun 2022 23:36:50 -0700	[thread overview]
Message-ID: <CAPANw+N_cXOiGT8ANqXvomCPhix6w9c6uFF7SUrPD2otpA+RuQ@mail.gmail.com> (raw)
In-Reply-To: <8735gm71kt.fsf@yahoo.com>

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



  parent reply	other threads:[~2022-06-10  6:36 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 [this message]
2022-06-03  6:57 ` Eli Zaretskii
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=CAPANw+N_cXOiGT8ANqXvomCPhix6w9c6uFF7SUrPD2otpA+RuQ@mail.gmail.com \
    --to=duncf@google.com \
    --cc=emacs-devel@gnu.org \
    --cc=luangruo@yahoo.com \
    /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).