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@gmail.com> wrote:

Nils Berg <nilsb@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.