GNU bug report logs - #23288
25.0.92; Clicking on links inserts primary X selection

Previous Next

Package: emacs;

Reported by: Philipp Stephani <p.stephani2 <at> gmail.com>

Date: Thu, 14 Apr 2016 12:32:02 UTC

Severity: normal

Tags: confirmed

Merged with 22434

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


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

From: Nils Berg <nilsb <at> google.com>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 23288 <at> debbugs.gnu.org
Subject: Re: bug#23288: 25.0.92; Clicking on links inserts primary X selection
Date: Mon, 18 Apr 2016 10:50:37 +0200
[Message part 1 (text/plain, inline)]
I applied the patch, and the paste-on-click behavior is gone.

However, if you try your original example again, you'll find that nothing
happens at all, when we're expecting an "a" to be inserted.
As the documentation of mouse-on-link-p says, a string or vector return
value indicates the event to translate the original mouse-1 click into. In
emacs24, that translation was done in mouse-drag-track:
(let (on-link (and mouse-1-click-follows-link
                       ;; Use start-point before the intangibility
                       ;; treatment, in case we click on a link inside
                       ;; intangible text.
  (mouse-on-link-p start-posn)))
  (if (or (vectorp on-link) (stringp on-link))
 (setq event (aref on-link 0))
(select-window original-window)
(setcar event 'mouse-2)
;; If this mouse click has never been done by the
;; user, it doesn't have the necessary property to be
;; interpreted correctly.
(put 'mouse-2 'event-kind 'mouse-click)))

(abridged from mouse.el:791/901 in Emacs 24.3.1)

I think mouse--down-1-maybe-follows-link should do something similar.

On Sat, Apr 16, 2016 at 3:36 PM, Philipp Stephani <p.stephani2 <at> gmail.com>
wrote:

>
>
> Nils Berg <nilsb <at> google.com> schrieb am Do., 14. Apr. 2016 um 19:18 Uhr:
>
>> I've tracked down the bug to mouse--down-1-maybe-follows-link too, but
>> don't think read-event is the culprit here.
>>
>> Rather, mouse--down-1-maybe-follows-link discards the result of
>> mouse-on-link-p, which contains the event a click is supposed to be
>> translated into. Instead, it just replaces the mouse event with mouse-2 if
>> mouse-on-link-p returns non-nil.
>>
>
> I've attached a patch that should fix this. According to the documentation
> of mouse-on-link-p no such translation should happen if the return value is
> a string or vector.
>
[Message part 2 (text/html, inline)]

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

Previous Next


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