Subject: bug#75219: 31.0.50; mouse-2 mode-line binding overridden by mouse-1-click-follows-link

From: Eli Zaretskii <[email-masked]>
Date: Sat, 11 Jan 2025 17:40:52 +0200

> From: Stefan Monnier <[email-masked]>
> Cc: [email-masked],  [email-masked]
> Date: Sat, 11 Jan 2025 10:11:47 -0500
> 
> > My only hesitation is whether we should do this with _any_ string or
> > only with mode-line and header-line strings.  If the string is a
> > display string or an overlay string, and the keymap properties of that
> > string at the click are nil, should we fall back on the keymap
> > properties at point, or should we ignore the buffer properties and
> > behave as if there are no keymap properties at the click?
> 
> I think for clicks on display strings, if the string's property is nil
> we should lookup the property at the position of the string (which IIUC
> is what you meant by "at point" above).

OK, I will therefore change the behavior only for mode-line and
header-line clicks.  It is also safer, in cases some Lisp out there
relies on the current (mis)behavior.

> This said, in my mind, it seems related to the question of whether the
> `face` property of an overlay (or a `face` text-property) should affect
> the visual appearance of a display string.  And AFAICT we don't have
> a consistent answer here: `after/before-string`s seem not to inherit faces
> from the context this way, whereas `display` strings seem to do.

That's true (it's documented in the ELisp reference), but faces are
somewhat different because we merge faces from available sources,
whereas keymap properties cannot be "merged".