bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Benjamin Riefenstahl
Subject: bug#22434: 25.0.50; recentf pastes X clipboard upon opening
Date: Sun, 22 May 2016 21:12:51 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.94 (gnu/linux)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]