* bug#22434: 25.0.50; recentf pastes X clipboard upon opening
@ 2016-01-22 6:20 Pascal A. Niklaus
2016-02-28 11:29 ` Yasushi SHOJI
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Pascal A. Niklaus @ 2016-01-22 6:20 UTC (permalink / raw)
To: 22434
[-- 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 --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22434: 25.0.50; recentf pastes X clipboard upon opening
2016-01-22 6:20 bug#22434: 25.0.50; recentf pastes X clipboard upon opening Pascal A. Niklaus
@ 2016-02-28 11:29 ` Yasushi SHOJI
2016-05-21 19:17 ` Paul Eggert
2016-05-22 17:14 ` Benjamin Riefenstahl
2 siblings, 0 replies; 20+ messages in thread
From: Yasushi SHOJI @ 2016-02-28 11:29 UTC (permalink / raw)
To: 22434
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22434: 25.0.50; recentf pastes X clipboard upon opening
2016-01-22 6:20 bug#22434: 25.0.50; recentf pastes X clipboard upon opening Pascal A. Niklaus
2016-02-28 11:29 ` Yasushi SHOJI
@ 2016-05-21 19:17 ` Paul Eggert
2016-05-21 20:32 ` Stefan Monnier
2016-05-22 17:14 ` Benjamin Riefenstahl
2 siblings, 1 reply; 20+ messages in thread
From: Paul Eggert @ 2016-05-21 19:17 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 22434
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22434: 25.0.50; recentf pastes X clipboard upon opening
2016-05-21 19:17 ` Paul Eggert
@ 2016-05-21 20:32 ` Stefan Monnier
0 siblings, 0 replies; 20+ messages in thread
From: Stefan Monnier @ 2016-05-21 20:32 UTC (permalink / raw)
To: Paul Eggert; +Cc: 22434
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22434: 25.0.50; recentf pastes X clipboard upon opening
2016-01-22 6:20 bug#22434: 25.0.50; recentf pastes X clipboard upon opening Pascal A. Niklaus
2016-02-28 11:29 ` Yasushi SHOJI
2016-05-21 19:17 ` Paul Eggert
@ 2016-05-22 17:14 ` Benjamin Riefenstahl
2016-05-22 17:30 ` Eli Zaretskii
2 siblings, 1 reply; 20+ messages in thread
From: Benjamin Riefenstahl @ 2016-05-22 17:14 UTC (permalink / raw)
To: 22434
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22434: 25.0.50; recentf pastes X clipboard upon opening
2016-05-22 17:14 ` Benjamin Riefenstahl
@ 2016-05-22 17:30 ` Eli Zaretskii
2016-05-22 19:12 ` Benjamin Riefenstahl
0 siblings, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2016-05-22 17:30 UTC (permalink / raw)
To: Benjamin Riefenstahl; +Cc: 22434
> 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)))
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22434: 25.0.50; recentf pastes X clipboard upon opening
2016-05-22 17:30 ` Eli Zaretskii
@ 2016-05-22 19:12 ` Benjamin Riefenstahl
2016-05-22 20:02 ` Benjamin Riefenstahl
0 siblings, 1 reply; 20+ messages in thread
From: Benjamin Riefenstahl @ 2016-05-22 19:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22434
> 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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22434: 25.0.50; recentf pastes X clipboard upon opening
2016-05-22 19:12 ` Benjamin Riefenstahl
@ 2016-05-22 20:02 ` Benjamin Riefenstahl
2016-05-24 16:11 ` Eli Zaretskii
0 siblings, 1 reply; 20+ messages in thread
From: Benjamin Riefenstahl @ 2016-05-22 20:02 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22434
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)
^ permalink raw reply related [flat|nested] 20+ messages in thread
* bug#22434: 25.0.50; recentf pastes X clipboard upon opening
2016-05-22 20:02 ` Benjamin Riefenstahl
@ 2016-05-24 16:11 ` Eli Zaretskii
2016-05-25 17:16 ` Benjamin Riefenstahl
0 siblings, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2016-05-24 16:11 UTC (permalink / raw)
To: Benjamin Riefenstahl; +Cc: 22434
> 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?
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22434: 25.0.50; recentf pastes X clipboard upon opening
2016-05-24 16:11 ` Eli Zaretskii
@ 2016-05-25 17:16 ` Benjamin Riefenstahl
2016-05-25 20:59 ` Stefan Monnier
0 siblings, 1 reply; 20+ messages in thread
From: Benjamin Riefenstahl @ 2016-05-25 17:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22434
[-- 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
^ permalink raw reply related [flat|nested] 20+ messages in thread
* bug#22434: 25.0.50; recentf pastes X clipboard upon opening
2016-05-25 17:16 ` Benjamin Riefenstahl
@ 2016-05-25 20:59 ` Stefan Monnier
2016-05-29 14:55 ` Stefan Monnier
0 siblings, 1 reply; 20+ messages in thread
From: Stefan Monnier @ 2016-05-25 20:59 UTC (permalink / raw)
To: Benjamin Riefenstahl; +Cc: 22434
> 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)
^ permalink raw reply related [flat|nested] 20+ messages in thread
* bug#22434: 25.0.50; recentf pastes X clipboard upon opening
2016-05-25 20:59 ` Stefan Monnier
@ 2016-05-29 14:55 ` Stefan Monnier
2016-05-29 16:52 ` Benjamin Riefenstahl
0 siblings, 1 reply; 20+ messages in thread
From: Stefan Monnier @ 2016-05-29 14:55 UTC (permalink / raw)
To: Benjamin Riefenstahl; +Cc: 22434
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)
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22434: 25.0.50; recentf pastes X clipboard upon opening
2016-05-29 14:55 ` Stefan Monnier
@ 2016-05-29 16:52 ` Benjamin Riefenstahl
2016-05-30 0:35 ` Stefan Monnier
2016-05-30 0:47 ` Stefan Monnier
0 siblings, 2 replies; 20+ messages in thread
From: Benjamin Riefenstahl @ 2016-05-29 16:52 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 22434
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22434: 25.0.50; recentf pastes X clipboard upon opening
2016-05-29 16:52 ` Benjamin Riefenstahl
@ 2016-05-30 0:35 ` Stefan Monnier
2016-05-30 15:41 ` Benjamin Riefenstahl
2016-05-30 0:47 ` Stefan Monnier
1 sibling, 1 reply; 20+ messages in thread
From: Stefan Monnier @ 2016-05-30 0:35 UTC (permalink / raw)
To: Benjamin Riefenstahl; +Cc: 22434
>>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22434: 25.0.50; recentf pastes X clipboard upon opening
2016-05-30 0:35 ` Stefan Monnier
@ 2016-05-30 15:41 ` Benjamin Riefenstahl
2016-05-30 16:35 ` Stefan Monnier
0 siblings, 1 reply; 20+ messages in thread
From: Benjamin Riefenstahl @ 2016-05-30 15:41 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 22434
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#22434: 25.0.50; recentf pastes X clipboard upon opening
2016-05-29 16:52 ` Benjamin Riefenstahl
2016-05-30 0:35 ` Stefan Monnier
@ 2016-05-30 0:47 ` Stefan Monnier
1 sibling, 0 replies; 20+ messages in thread
From: Stefan Monnier @ 2016-05-30 0:47 UTC (permalink / raw)
To: Benjamin Riefenstahl; +Cc: 22434
>>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2016-05-31 19:17 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-01-22 6:20 bug#22434: 25.0.50; recentf pastes X clipboard upon opening Pascal A. Niklaus
2016-02-28 11:29 ` Yasushi SHOJI
2016-05-21 19:17 ` Paul Eggert
2016-05-21 20:32 ` Stefan Monnier
2016-05-22 17:14 ` Benjamin Riefenstahl
2016-05-22 17:30 ` Eli Zaretskii
2016-05-22 19:12 ` Benjamin Riefenstahl
2016-05-22 20:02 ` Benjamin Riefenstahl
2016-05-24 16:11 ` Eli Zaretskii
2016-05-25 17:16 ` Benjamin Riefenstahl
2016-05-25 20:59 ` Stefan Monnier
2016-05-29 14:55 ` Stefan Monnier
2016-05-29 16:52 ` Benjamin Riefenstahl
2016-05-30 0:35 ` Stefan Monnier
2016-05-30 15:41 ` Benjamin Riefenstahl
2016-05-30 16:35 ` Stefan Monnier
2016-05-30 16:48 ` Benjamin Riefenstahl
2016-05-31 0:46 ` Stefan Monnier
2016-05-31 19:17 ` Benjamin Riefenstahl
2016-05-30 0:47 ` Stefan Monnier
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.