GNU bug report logs - #22434
25.0.50; recentf pastes X clipboard upon opening

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22434 in the body.
You can then email your comments to 22434 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Pascal A. Niklaus" <pascal.niklaus <at> ieu.uzh.ch>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.50; recentf pastes X clipboard upon opening
Date: Fri, 22 Jan 2016 07:20:47 +0100

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Message #12 received at 22434 <at> debbugs.gnu.org (full text, mbox):

From: Yasushi SHOJI <yashi <at> atmark-techno.com>
To: 22434 <at> debbugs.gnu.org
Subject: Re: 25.0.50; recentf pastes X clipboard upon opening
Date: Sun, 28 Feb 2016 20:29:10 +0900

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.

Message #17 received at 22434 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 22434 <at> debbugs.gnu.org
Subject: Re: 25.0.50; recentf pastes X clipboard upon opening
Date: Sat, 21 May 2016 12:17:56 -0700

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.

Message #20 received at 22434 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 22434 <at> debbugs.gnu.org
Subject: Re: 25.0.50; recentf pastes X clipboard upon opening
Date: Sat, 21 May 2016 16:32:17 -0400

> 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

Message #23 received at 22434 <at> debbugs.gnu.org (full text, mbox):

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: 22434 <at> debbugs.gnu.org
Subject: 25.0.50; recentf pastes X clipboard upon opening
Date: Sun, 22 May 2016 19:14:50 +0200

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.

Message #26 received at 22434 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
Cc: 22434 <at> debbugs.gnu.org
Subject: Re: bug#22434: 25.0.50; recentf pastes X clipboard upon opening
Date: Sun, 22 May 2016 20:30:29 +0300

> From: Benjamin Riefenstahl <b.riefenstahl <at> 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)))

Message #29 received at 22434 <at> debbugs.gnu.org (full text, mbox):

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22434 <at> debbugs.gnu.org
Subject: Re: bug#22434: 25.0.50; recentf pastes X clipboard upon opening
Date: Sun, 22 May 2016 21:12:51 +0200

> From: Benjamin Riefenstahl <b.riefenstahl <at> 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.

Message #32 received at 22434 <at> debbugs.gnu.org (full text, mbox):

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22434 <at> debbugs.gnu.org
Subject: Re: bug#22434: 25.0.50; recentf pastes X clipboard upon opening
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:

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)

Message #35 received at 22434 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
Cc: 22434 <at> debbugs.gnu.org
Subject: Re: bug#22434: 25.0.50; recentf pastes X clipboard upon opening
Date: Tue, 24 May 2016 19:11:29 +0300

> From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
> Cc: 22434 <at> 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?

Message #38 received at 22434 <at> debbugs.gnu.org (full text, mbox):

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22434 <at> debbugs.gnu.org
Subject: Re: bug#22434: 25.0.50; recentf pastes X clipboard upon opening
Date: Wed, 25 May 2016 19:16:40 +0200

[Message part 1 (text/plain, inline)]

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

[0001-Fix-bug-22434-recentf-pastes-X-clipboard.patch (text/x-diff, attachment)]

Message #41 received at 22434 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22434 <at> debbugs.gnu.org
Subject: Re: bug#22434: 25.0.50; recentf pastes X clipboard upon opening
Date: Wed, 25 May 2016 16:59:14 -0400

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

Message #44 received at 22434 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22434 <at> debbugs.gnu.org
Subject: Re: bug#22434: 25.0.50; recentf pastes X clipboard upon opening
Date: Sun, 29 May 2016 10:55:08 -0400

Ping?


        Stefan


>>>>> "Stefan" == Stefan Monnier <monnier <at> 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)

Message #47 received at 22434 <at> debbugs.gnu.org (full text, mbox):

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22434 <at> debbugs.gnu.org
Subject: Re: bug#22434: 25.0.50; recentf pastes X clipboard upon opening
Date: Sun, 29 May 2016 18:52:31 +0200

Stefan Monnier writes:
> Ping?

Sorry for the delay.

>>>>>> "Stefan" == Stefan Monnier <monnier <at> 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

Message #50 received at 22434 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22434 <at> debbugs.gnu.org
Subject: Re: bug#22434: 25.0.50; recentf pastes X clipboard upon opening
Date: Sun, 29 May 2016 20:35:23 -0400

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

Message #53 received at 22434 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22434 <at> debbugs.gnu.org
Subject: Re: bug#22434: 25.0.50; recentf pastes X clipboard upon opening
Date: Sun, 29 May 2016 20:47:21 -0400

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

Message #56 received at 22434 <at> debbugs.gnu.org (full text, mbox):

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22434 <at> debbugs.gnu.org
Subject: Re: bug#22434: 25.0.50; recentf pastes X clipboard upon opening
Date: Mon, 30 May 2016 17:41:04 +0200

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

Message #59 received at 22434 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22434 <at> debbugs.gnu.org
Subject: Re: bug#22434: 25.0.50; recentf pastes X clipboard upon opening
Date: Mon, 30 May 2016 12:35:09 -0400

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

Message #62 received at 22434 <at> debbugs.gnu.org (full text, mbox):

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22434 <at> debbugs.gnu.org
Subject: Re: bug#22434: 25.0.50; recentf pastes X clipboard upon opening
Date: Mon, 30 May 2016 18:48:39 +0200

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

Message #67 received at 22434-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22434-done <at> debbugs.gnu.org
Subject: Re: bug#22434: 25.0.50; recentf pastes X clipboard upon opening
Date: Mon, 30 May 2016 20:46:56 -0400

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

Sorry 'bout that.  Installed,


        Stefan

Message #75 received at 22434-done <at> debbugs.gnu.org (full text, mbox):

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Eli Zaretskii <eliz <at> gnu.org>,
 "Pascal A. Niklaus" <pascal.niklaus <at> ieu.uzh.ch>, 22434-done <at> debbugs.gnu.org
Subject: Re: bug#22434: 25.0.50; recentf pastes X clipboard upon opening
Date: Tue, 31 May 2016 21:17:49 +0200

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

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

benny

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.