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
Message #32 received at 76620 <at> debbugs.gnu.org (full text, mbox):
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li, monnier <at> iro.umontreal.ca
> 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.
Ah, okay. But what does this have to do with mouse-2 vs mouse-1?
This bug report was last modified 10 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.