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

Previous Next

Package: emacs;

Reported by: "Pascal A. Niklaus" <pascal.niklaus <at> ieu.uzh.ch>

Date: Fri, 22 Jan 2016 15:54:01 UTC

Severity: normal

Tags: confirmed

Merged with 23288

Found in versions 25.0.50, 25.0.92

Done: Stefan Monnier <monnier <at> IRO.UMontreal.CA>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22434 <at> debbugs.gnu.org
Subject: 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.




This bug report was last modified 9 years and 45 days ago.

Previous Next


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