GNU bug report logs -
#75219
31.0.50; mouse-2 mode-line binding overridden by mouse-1-click-follows-link
Previous Next
Reported by: Visuwesh <visuweshm <at> gmail.com>
Date: Tue, 31 Dec 2024 05:40:02 UTC
Severity: normal
Found in version 31.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: visuweshm <at> gmail.com, 75219 <at> debbugs.gnu.org
> 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".
This bug report was last modified 186 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.