GNU bug report logs - #76620
30.1.50; mouse-1 mode-line bindings are unusable when point is on a button

Previous Next

Full log

View this message in rfc822 format

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li, monnier <at> iro.umontreal.ca
Subject: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable when point is on a button
Date: Sat, 30 Aug 2025 09:37:46 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  76620 <at> debbugs.gnu.org,
>>    jonas <at> bernoul.li
>> Date: Thu, 28 Aug 2025 14:22:32 -0400
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> Cc: Jonas Bernoulli <jonas <at> bernoul.li>
>> >> Date: Thu, 27 Feb 2025 18:11:36 -0500
>> >> From:  Spencer Baugh via "Bug reports for GNU Emacs,
>> >>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> >> 
>> >> 
>> >> 1. emacs -Q
>> >> 2. Position point over a button.el button, e.g.
>> >>    (progn (view-emacs-news) (forward-button 1))
>> >> 3. mouse-2 anywhere on the mode line.
>> >> 4. Note that instead of the usual mouse-delete-other-windows binding,
>> >>    the button at point is activated.
>> >> 
>> >> This is because the local keymap for buttons is button-map, which binds
>> >> "<mode-line> <mouse-2>".  This is confusing, and probably a bug, but not
>> >> too bad of a bug.
>> >> 
>> >> Substantially worse is this:
>> >> 
>> >> 5. mouse-1 on a part of the mode-line with a mouse-1 binding; for
>> >>    example, mouse-1 on the buffer coding system indicator "U" at the
>> >>    start of the mode line.
>> >> 
>> >> 6. Instead of describing the buffer's coding system, the button at point
>> >>    is activated.
>> >> 
>> >> This is because mouse-1-click-follows-link translates the mouse-1 into a
>> >> mouse-2.  This makes all mouse-1 bindings on the mode line basically
>> >> broken while point is on a button.
>> >
>> > The bugs with mouse-1 are solved on the master branch (see bug#75219).
>> > So I can reproduce the last two items in Emacs 30, but not in Emacs
>> > 31.  The problems with mouse-2 are still present on the master branch.
>> 
>> The attached patch should fix the remaining bug, without dropping
>> support for button.el in the mode-line or header-line.
>> 
>> >From 1ebb6e8822b5fc635549be14a3d4f2dd6f2d77a4 Mon Sep 17 00:00:00 2001
>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Date: Thu, 28 Aug 2025 14:13:24 -0400
>> Subject: [PATCH] Always ignore keymaps at point when clicking mode and header
>>  line
>> 
>> In c41ea047a43, we started ignoring the keymap at point when a
>> position is a click on the mode line or header line.  However,
>> we only did this when POSN_STRING was non-nil, which isn't
>> always the case for clicks on the mode line and header line.
>> Move the check for mode line or header line outside the check
>> for non-nil POSN_STRING so it takes effect in that case.
>> 
>> * src/keymap.c (Fcurrent_active_maps): Ignore keymaps at point
>> for all clicks on mode and header line.  (bug#76620)
>
> I'm not sure I understand the logic of this change, so please
> elaborate, by showing the form(s) of POSITION for which the current
> code doesn't work, and please explain how this patch fixes that.

When you click on a part of the mode line which is after the end of
mode-line-format, (at least on GNU/Linux) you get an event like this:

(down-mouse-1 (#<window 3 on *Bugs*> mode-line (2379 . 2071) 21536370
 nil nil (157 . 88) nil (8 . 19) (15 . 32)))

posn-string is nil for this but it's still in the mode-line.  My change
checks for whether a position is in the mode-line before checking if
posn-string is nil, so it catches such events.

Previous Next

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