bug#22434: 25.0.50; recentf pastes X clipboard upon opening

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Pascal A. Niklaus]

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

When opening a file with recentf-open-files, the X clipboard content is

pasted into the opened file, where the mouse pointer is at that moment.


To reproduce this behaviour:


Start emacs with "emacs -Q"


Evaluate to following lines: (M-:)

(require 'recentf)

(recentf-mode 1)


Fill the clipboard with something by selecting some text (in e.g. a 
terminal window... text that would typically be pasted by a

middle button click)


M-x recentf-open-files


Choose a file from the menu

In my setup at least, the selected text is pasted into the file right 
where the

mouse pointer was when I chose the file from recentf's menu with a

left-click.



In GNU Emacs 25.0.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)

of 2015-10-28 on pnX230

Windowing system distributor `The X.Org Foundation', version 11.0.11501000

System Description: Linux Mint 17.2 Rafaela


Configured features:

XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS

NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB


Important settings:

value of $LC_MONETARY: de_CH.UTF-8

value of $LC_NUMERIC: de_CH.UTF-8

value of $LC_TIME: en_DK.utf8

value of $LANG: en_US.UTF-8

locale-coding-system: utf-8-unix


Major mode: C/l


Minor modes in effect:

diff-auto-refine-mode: t

shell-dirtrack-mode: t

recentf-mode: t

tooltip-mode: t

global-eldoc-mode: t

electric-indent-mode: t

mouse-wheel-mode: t

tool-bar-mode: t

menu-bar-mode: t

file-name-shadow-mode: t

global-font-lock-mode: t

font-lock-mode: t

blink-cursor-mode: t

auto-composition-mode: t

auto-encryption-mode: t

auto-compression-mode: t

line-number-mode: t

abbrev-mode: t


Recent messages:

Making completion list...

Loading /home/...my-user-name....../.emacs.d/recentf...done

Cleaning up the recentf list...done (0 removed)

t

25 (#o31, #x19, ?\C-y)

Mark set

Making completion list... [3 times]

Open /file-name-removed.../filename

Mark set

Undo!


Load-path shadows:

None found.


Features:

(shadow sort mail-extr emacsbug message dired rfc822 mml mml-sec

mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils

mailheader sendmail rfc2047 rfc2045 ietf-drums mail-utils vc-git

diff-mode easy-mmode cc-mode cc-fonts cc-guess cc-menus cc-cmds

cc-styles cc-align cc-engine cc-vars cc-defs tramp-cache tramp-sh tramp

tramp-compat auth-source cl-macs cl-seq eieio byte-opt gv bytecomp

byte-compile cl-extra seq cconv eieio-core gnus-util mm-util mail-prsvr

password-cache tramp-loaddefs trampver shell pcomplete comint ansi-color

ring format-spec advice help-fns recentf tree-widget wid-edit

cl-loaddefs pcase cl-lib easymenu time-date mule-util tooltip eldoc

electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win

term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe

tabulated-list newcomment elisp-mode lisp-mode prog-mode register page

menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock

syntax facemenu font-core frame cl-generic cham georgian utf-8-lang

misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms

cp51932 hebrew greek romanian slovak czech european ethiopic indian

cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev

minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp

files text-properties overlay sha1 md5 base64 format env code-pages mule

custom widget hashtable-print-readable backquote dbusbind gfilenotify

dynamic-setting system-font-setting font-render-setting move-toolbar gtk

x-toolkit x multi-tty make-network-process emacs)


Memory information:

((conses 16 127118 7299)

(symbols 48 24176 1)

(miscs 40 170 115)

(strings 32 29125 4789)

(string-bytes 1 1014631)

(vectors 16 17393)

(vector-slots 8 471761 6290)

(floats 8 163 51)

(intervals 56 424 2)

(buffers 976 13)

(heap 1024 31663 1058))


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

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Yasushi SHOJI]

I've tracked down with git bisect to

18b8557f5ab154625d72891bdb982da14091da4d

which is a fix to #18015

http://debbugs.gnu.org/18015

In the commit `mouse--down-1-maybe-follows-link' is changed to read
event using `read-key' instead of `read-event'.  Changing back to
`read-event' fixes this bug, however, I assume that will re-introduce
the xterm-mouse-mode problem.

Mouse 1 event is converted to Mouse 2 event, which is an event to past
X selection.

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Paul Eggert]

Stefan, it appears that your commit 18b8557f5ab154625d72891bdb982da14091da4d 
dated 2014-10-21 is associated with Bug#22434, which is listed as a blocker for 
Emacs 25. Could you please take a look at it and let us know what you think? Thanks.

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Stefan Monnier]

> Stefan, it appears that your commit 18b8557f5ab154625d72891bdb982da14091da4d
> dated 2014-10-21 is associated with Bug#22434, which is listed as a blocker
> for Emacs 25. Could you please take a look at it and let us know what you
> think? Thanks.

I'll take a look, thanks,


        Stefan

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Benjamin Riefenstahl]

For the record, I can reproduce this.

Additional notes for the recipe:

> M-x recentf-open-files

One needs to have a recentf file "~/.emacs.d/recentf" from a previous
use at this point.

> Choose a file from the menu.

Choose using the mouse.


<mouse-button> C-h l results in this log:

   <help-echo> <help-echo> <down-mouse-1> <mouse-1> <mouse-1>
   [widget-button-click]
   <mouse-2> [mouse-yank-primary]
   C-h l [view-lossage]

From where does the <mouse-2> come here?


Reviewing Stefan's change, reverting this hunk in lisp/mouse.el fixes
the issue for me, but than that change was intentional of course :-( :

  @@ -112,7 +111,7 @@ mouse--down-1-maybe-follows-link
                 timedout (not timedout))
             nil

  -        (let ((event (read-event)))
  +        (let ((event (read-key))) ;Use read-key so it works for xterm-mouse-mode!
             (if (eq (car-safe event) (if (eq mouse-1-click-follows-link 'double)
                                          'double-mouse-1 'mouse-1))
                 ;; Turn the mouse-1 into a mouse-2 to follow links.

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Eli Zaretskii]

> From: Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>
> Date: Sun, 22 May 2016 19:14:50 +0200
> 
> <mouse-button> C-h l results in this log:
> 
>    <help-echo> <help-echo> <down-mouse-1> <mouse-1> <mouse-1>
>    [widget-button-click]
>    <mouse-2> [mouse-yank-primary]
>    C-h l [view-lossage]
> 
> >From where does the <mouse-2> come here?

See below:

>   @@ -112,7 +111,7 @@ mouse--down-1-maybe-follows-link
>                  timedout (not timedout))
>              nil
> 
>   -        (let ((event (read-event)))
>   +        (let ((event (read-key))) ;Use read-key so it works for xterm-mouse-mode!
>              (if (eq (car-safe event) (if (eq mouse-1-click-follows-link 'double)
>                                           'double-mouse-1 'mouse-1))
>                  ;; Turn the mouse-1 into a mouse-2 to follow links.
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Which continues:

              (let ((newup (if (eq mouse-1-click-follows-link 'double)
                                'double-mouse-2 'mouse-2)))

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Benjamin Riefenstahl]

> From: Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>
>> From where does the <mouse-2> come here?

Eli Zaretskii writes:
> See below:
>
>>   @@ -112,7 +111,7 @@ mouse--down-1-maybe-follows-link
>>                  timedout (not timedout))
>>              nil
>> 
>>   -        (let ((event (read-event)))
>>   +        (let ((event (read-key))) ;Use read-key so it works for xterm-mouse-mode!
>>              (if (eq (car-safe event) (if (eq mouse-1-click-follows-link 'double)
>>                                           'double-mouse-1 'mouse-1))
>>                  ;; Turn the mouse-1 into a mouse-2 to follow links.
>                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Which continues:
>
>               (let ((newup (if (eq mouse-1-click-follows-link 'double)
>                                 'double-mouse-2 'mouse-2)))

Right.

I also see now that bug #23288 had a solution, but it does not work for
me in this case.  It depends on mouse-on-link-p to return a string or a
vector, but what I get at this point is just t.  Inside mouse-on-link-p
the first branch of the cond is taken, because the follow-link property
is 'mouse-face.

This whole translation business seems fishy to me.

There is no check that the cursor or at least the window are still the
same when the mouse-2 handler is eventually called (it isn't here, I
believe).

There is no check that mouse-2 is actually bound to anything meaningfull
that we want in addition to the mouse-1 handler.  And what is the formal
definition of 'meaningfull' here?

And why is there a need to fall back to a mouse-2 handler when there is
an explicit handler for mouse-1 already, widget-button-click in this
case?  Let the mouse-1 handler do what it wants to have done.

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Benjamin Riefenstahl]

Benjamin Riefenstahl writes:
> I also see now that bug #23288 had a solution, but it does not work for
> me in this case.  It depends on mouse-on-link-p to return a string or a
> vector, but what I get at this point is just t.  Inside mouse-on-link-p
> the first branch of the cond is taken, because the follow-link property
> is 'mouse-face.

I can make it work with the patch from #23288, when I also add this
change to trigger the new code:

diff --git a/lisp/recentf.el b/lisp/recentf.el
index df7f3e2..f241cd4 100644
--- a/lisp/recentf.el
+++ b/lisp/recentf.el
@@ -1187,6 +1187,7 @@ recentf-open-files-item
            :format "%[%t\n%]"
            :help-echo ,(concat "Open " (cdr menu-element))
            :action recentf-open-files-action
+           :follow-link [ignore]
            ,(cdr menu-element))))
 
 (defun recentf-open-files-items (files)

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Eli Zaretskii]

> From: Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>
> Cc: 22434@debbugs.gnu.org
> Date: Sun, 22 May 2016 22:02:10 +0200
> 
> Benjamin Riefenstahl writes:
> > I also see now that bug #23288 had a solution, but it does not work for
> > me in this case.  It depends on mouse-on-link-p to return a string or a
> > vector, but what I get at this point is just t.  Inside mouse-on-link-p
> > the first branch of the cond is taken, because the follow-link property
> > is 'mouse-face.
> 
> I can make it work with the patch from #23288, when I also add this
> change to trigger the new code:

Thanks, but we'd prefer to have a solution for this bug that doesn't
require the #23288 patch, so we could fix recentf on the release
branch.  Could you perhaps come up with such a patch?

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Benjamin Riefenstahl]

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

Hi Eli,

Eli Zaretskii writes:
> Thanks, but we'd prefer to have a solution for this bug that doesn't
> require the #23288 patch, so we could fix recentf on the release
> branch.  Could you perhaps come up with such a patch?

Does the attached fit the bill?  It works for me.  I hope I got the
formalities right.

IMO on master we really should either fix
mouse--down-1-maybe-follows-link like in #23288 or re-think this
strategy of generating an event for some random unknown consumer.

so long, benny


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-bug-22434-recentf-pastes-X-clipboard.patch --]
[-- Type: text/x-diff, Size: 2421 bytes --]

From f1e368b62f9cb817c23bf1933f6820815ec20609 Mon Sep 17 00:00:00 2001
From: Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>
Date: Wed, 25 May 2016 19:03:36 +0200
Subject: [PATCH] Fix bug#22434, recentf pastes X clipboard

A quick hack to avoid bug#22434.  Introduces a special symbol for this
purpose.
* lisp/mouse.el (mouse--down-1-maybe-follows-link): React to
'do-not-follow-link.
* lisp/recentf.el (recentf-open-files-item): Set :follow-link to
'do-not-follow-link.
---
 lisp/mouse.el   | 9 ++++++++-
 lisp/recentf.el | 6 ++++++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/lisp/mouse.el b/lisp/mouse.el
index fa355ff..4c31d65 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -98,7 +98,14 @@ mouse--down-1-maybe-follows-link
              (eq (if (eq mouse-1-click-follows-link 'double)
                      'double-down-mouse-1 'down-mouse-1)
                  (car-safe last-input-event))
-             (mouse-on-link-p (event-start last-input-event))
+             ;; Hack: Conspire with recentf-open-files-item to not do
+             ;; this in the recentf-open-files dialog.  The documented
+             ;; way would be to set :follow-link to a string or vector
+             ;; with a do-nothing event, but that does not work at
+             ;; this point, because this function does not implement
+             ;; that aspect.
+             (let ((action (mouse-on-link-p (event-start last-input-event))))
+               (and action (not (eq action 'do-not-follow-link))))
              (or mouse-1-click-in-non-selected-windows
                  (eq (selected-window)
                      (posn-window (event-start last-input-event)))))
diff --git a/lisp/recentf.el b/lisp/recentf.el
index df7f3e2..15114e3 100644
--- a/lisp/recentf.el
+++ b/lisp/recentf.el
@@ -1187,6 +1187,12 @@ recentf-open-files-item
            :format "%[%t\n%]"
            :help-echo ,(concat "Open " (cdr menu-element))
            :action recentf-open-files-action
+           ;; Hack: Conspire with mouse--down-1-maybe-follows-link to
+           ;; not add a spurious mouse-2 event.  The documented way
+           ;; would be to set :follow-link to a string or vector with
+           ;; a do-nothing event, but that does not work at this
+           ;; point.
+           :follow-link do-not-follow-link
            ,(cdr menu-element))))
 
 (defun recentf-open-files-items (files)
-- 
2.1.4

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Stefan Monnier]

> Does the attached fit the bill?  It works for me.  I hope I got the
> formalities right.

> IMO on master we really should either fix
> mouse--down-1-maybe-follows-link like in #23288 or re-think this
> strategy of generating an event for some random unknown consumer.

Thinking about it some more, I think we have a deeper problem: it's not
just for these recentf buttons that we shouldn't remap mouse-1 to
mouse-2.  It's for all widget buttons that have a mouse-1 binding to
widget-button-click (of course, I consider the `down-mouse-1' binding to
widget-button-click to be a bug as well (it should be bound to `mouse-1'
instead) but I'd rather not touch this for now).

The mouse-1 to mouse-2 remapping is to magically let mouse-1 work for
"follow-link" depending on the value of mouse-1-click-follows-link, but
here mouse-1 will always follow the link anyway, so remapping
is undesirable.

AFAIK we inherit the follow-link property from wid-edit's

    (define-widget 'link 'item
      "An embedded link."
      :button-prefix 'widget-link-prefix
      :button-suffix 'widget-link-suffix
      :follow-link 'mouse-face
      :help-echo "Follow the link."
      :format "%[%t%]")

but I don't understand why we need this follow-link property there.

I understand that changing this part of wid-edit in emacs-25 is too
risky at this stage, so we'll probably want some stop-gap fix in the
mean time, but I'd prefer for the stop-gap not to add too much ugly hack.

How 'bout the patch below, which seems to do the trick for me?


        Stefan


diff --git a/lisp/recentf.el b/lisp/recentf.el
index df7f3e2..cab4a27 100644
--- a/lisp/recentf.el
+++ b/lisp/recentf.el
@@ -1064,7 +1064,7 @@ recentf-dialog-mode-map
     (define-key km "q" 'recentf-cancel-dialog)
     (define-key km "n" 'next-line)
     (define-key km "p" 'previous-line)
-    (define-key km [follow-link] "\C-m")
+    ;; (define-key km [follow-link] "\C-m")
     km)
   "Keymap used in recentf dialogs.")
 
@@ -1186,7 +1186,10 @@ recentf-open-files-item
            :button-face default
            :format "%[%t\n%]"
            :help-echo ,(concat "Open " (cdr menu-element))
-           :action recentf-open-files-action
+           :action ,#'recentf-open-files-action
+           ;; Override the (problematic) follow-link property of the
+           ;; `link' widget (bug#22434).
+           :follow-link nil
            ,(cdr menu-element))))
 
 (defun recentf-open-files-items (files)

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Stefan Monnier]

Ping?


        Stefan


>>>>> "Stefan" == Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Does the attached fit the bill?  It works for me.  I hope I got the
>> formalities right.

>> IMO on master we really should either fix
>> mouse--down-1-maybe-follows-link like in #23288 or re-think this
>> strategy of generating an event for some random unknown consumer.

> Thinking about it some more, I think we have a deeper problem: it's not
> just for these recentf buttons that we shouldn't remap mouse-1 to
> mouse-2.  It's for all widget buttons that have a mouse-1 binding to
> widget-button-click (of course, I consider the `down-mouse-1' binding to
> widget-button-click to be a bug as well (it should be bound to `mouse-1'
> instead) but I'd rather not touch this for now).

> The mouse-1 to mouse-2 remapping is to magically let mouse-1 work for
> "follow-link" depending on the value of mouse-1-click-follows-link, but
> here mouse-1 will always follow the link anyway, so remapping
> is undesirable.

> AFAIK we inherit the follow-link property from wid-edit's

>     (define-widget 'link 'item
>       "An embedded link."
>       :button-prefix 'widget-link-prefix
>       :button-suffix 'widget-link-suffix
>       :follow-link 'mouse-face
>       :help-echo "Follow the link."
>       :format "%[%t%]")

> but I don't understand why we need this follow-link property there.

> I understand that changing this part of wid-edit in emacs-25 is too
> risky at this stage, so we'll probably want some stop-gap fix in the
> mean time, but I'd prefer for the stop-gap not to add too much ugly hack.

> How 'bout the patch below, which seems to do the trick for me?


>         Stefan


> diff --git a/lisp/recentf.el b/lisp/recentf.el
> index df7f3e2..cab4a27 100644
> --- a/lisp/recentf.el
> +++ b/lisp/recentf.el
> @@ -1064,7 +1064,7 @@ recentf-dialog-mode-map
>      (define-key km "q" 'recentf-cancel-dialog)
>      (define-key km "n" 'next-line)
>      (define-key km "p" 'previous-line)
> -    (define-key km [follow-link] "\C-m")
> +    ;; (define-key km [follow-link] "\C-m")
>      km)
>    "Keymap used in recentf dialogs.")
 
> @@ -1186,7 +1186,10 @@ recentf-open-files-item
>             :button-face default
>             :format "%[%t\n%]"
>             :help-echo ,(concat "Open " (cdr menu-element))
> -           :action recentf-open-files-action
> +           :action ,#'recentf-open-files-action
> +           ;; Override the (problematic) follow-link property of the
> +           ;; `link' widget (bug#22434).
> +           :follow-link nil
>             ,(cdr menu-element))))
 
>  (defun recentf-open-files-items (files)

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Benjamin Riefenstahl]

Stefan Monnier writes:
> Ping?

Sorry for the delay.

>>>>>> "Stefan" == Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> How 'bout the patch below, which seems to do the trick for me?

Works for me, too.

>> AFAIK we inherit the follow-link property from wid-edit's
>
>>     (define-widget 'link 'item
>>       "An embedded link."
>>       :button-prefix 'widget-link-prefix
>>       :button-suffix 'widget-link-suffix
>>       :follow-link 'mouse-face
>>       :help-echo "Follow the link."
>>       :format "%[%t%]")
>
>> but I don't understand why we need this follow-link property there.

In principle we probably don't.  Unless the property has some other use,
I haven't studied this yet enough to say.  Removing it would of course
change the functionality, as we see in our use case here.

benny

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Stefan Monnier]

>>> How 'bout the patch below, which seems to do the trick for me?
> Works for me, too.

Thanks, I installed only the second hunk since it seems to be sufficient.


        Stefan

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Benjamin Riefenstahl]

Stefan Monnier writes:
> Thanks, I installed only the second hunk since it seems to be sufficient.

With only that, I can still reproduce the problem.  If I read this
right, mouse-on-link-p first looks at the property follow-link and it
that is not set, it looks at the keybinding for follow-link.

Stefan Monnier writes:
> I believe 22434 can be closed now, right?

When the key binding is deactivated, yes, that should be enough here.

benny

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Stefan Monnier]

>> I believe 22434 can be closed now, right?
> When the key binding is deactivated, yes, that should be enough here.

OK.  Can you install that change into emacs-25 for me?


        Stefan

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Benjamin Riefenstahl]

Stefan Monnier writes:
> OK.  Can you install that change into emacs-25 for me?

I don't have access.

@Eli, can you install it?  We were talking about:

diff --git a/lisp/recentf.el b/lisp/recentf.el
index df7f3e2..cab4a27 100644
--- a/lisp/recentf.el
+++ b/lisp/recentf.el
@@ -1064,7 +1064,7 @@ recentf-dialog-mode-map
     (define-key km "q" 'recentf-cancel-dialog)
     (define-key km "n" 'next-line)
     (define-key km "p" 'previous-line)
-    (define-key km [follow-link] "\C-m")
+    ;; (define-key km [follow-link] "\C-m")
     km)
   "Keymap used in recentf dialogs.")
 

benny

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Stefan Monnier]

>> OK.  Can you install that change into emacs-25 for me?
> I don't have access.

Sorry 'bout that.  Installed,


        Stefan

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Benjamin Riefenstahl]

Stefan Monnier writes:
> Sorry 'bout that.  Installed,

No problem.  It works for me now, so from my side it can be closed.

benny

bug#22434: 25.0.50; recentf pastes X clipboard upon opening

[Stefan Monnier]

>>> but I don't understand why we need this follow-link property there.
> In principle we probably don't.  Unless the property has some other use,
> I haven't studied this yet enough to say.  Removing it would of course
> change the functionality, as we see in our use case here.

I removed it in the `master' branch.

I believe 22434 can be closed now, right?


        Stefan