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

Previous Next

To reply to this bug, email your comments to 76620 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1.50; mouse-1 mode-line bindings are unusable when point is on a
 button
Date: Thu, 27 Feb 2025 18:11:36 -0500

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 mode-line (and header-line) binding was added to button.el in
24fc9480399b2d018e8d85f34e9c5d8c327ce3bf to support using buttons in the
mode-line and header-line.  I suggest that we should remove those
bindings, in favor of some other way to use button.el in the mode-line
or header-line.  Especially because, from grepping through ~400 popular
packages (the ones installed at my site), I see no usage of buttons in
the mode-line or header-line.


In GNU Emacs 30.1.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2025-02-24 built on
 igm-qws-u22796a
Repository revision: b3f0c1a30a1fee5a81b7a0c6c7f52ec0ef5bade6
Repository branch: emacs-30
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Rocky Linux 8.10 (Green Obsidian)

Configured using:
 'configure --config-cache --with-x-toolkit=lucid --without-gpm
 --without-gconf --without-selinux --without-imagemagick --with-modules
 --with-gif=no --with-cairo --with-rsvg --without-compress-install
 --with-tree-sitter'

Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSYSTEMD
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM
XINPUT2 XPM LUCID ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr compile comint ansi-osc ansi-color ring comp-run
bytecomp byte-compile comp-common rx emacsbug message mailcap yank-media
puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived
epg rfc6068 epg-config gnus-util text-property-search time-date subr-x
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty move-toolbar make-network-process native-compile
emacs)

Memory information:
((conses 16 92421 9053) (symbols 48 6739 0) (strings 32 26097 2919)
 (string-bytes 1 786157) (vectors 16 16424)
 (vector-slots 8 188776 8192) (floats 8 37 1) (intervals 56 320 0)
 (buffers 992 11))

Message #8 received at 76620 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li
Subject: Re: bug#76620: 30.1.50;
 mouse-1 mode-line bindings are unusable when point is on a button
Date: Fri, 28 Feb 2025 09:52:10 +0200

> 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 mode-line (and header-line) binding was added to button.el in
> 24fc9480399b2d018e8d85f34e9c5d8c327ce3bf to support using buttons in the
> mode-line and header-line.  I suggest that we should remove those
> bindings, in favor of some other way to use button.el in the mode-line
> or header-line.  Especially because, from grepping through ~400 popular
> packages (the ones installed at my site), I see no usage of buttons in
> the mode-line or header-line.

Adding Stefan to the discussion.

Message #11 received at 76620 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: sbaugh <at> janestreet.com, monnier <at> iro.umontreal.ca
Cc: 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li
Subject: Re: bug#76620: 30.1.50;
 mouse-1 mode-line bindings are unusable when point is on a button
Date: Fri, 28 Feb 2025 10:27:04 +0200

> Cc: 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li
> Date: Fri, 28 Feb 2025 09:52:10 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > 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.

I've now cherry-picked that fix to the emacs-30 branch, so the issues
with mouse-1 on the mode line in this situation should be solved in
Emacs 30.2.

Message #14 received at 76620 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 76620 <at> debbugs.gnu.org,
 jonas <at> bernoul.li
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Fri, 28 Feb 2025 10:44:00 -0500

>> The mode-line (and header-line) binding was added to button.el in
>> 24fc9480399b2d018e8d85f34e9c5d8c327ce3bf to support using buttons in the
>> mode-line and header-line.  I suggest that we should remove those
>> bindings, in favor of some other way to use button.el in the mode-line
>> or header-line.  Especially because, from grepping through ~400 popular
>> packages (the ones installed at my site), I see no usage of buttons in
>> the mode-line or header-line.
>
> Adding Stefan to the discussion.

FWIW, I've used code which used the same text (with buttons) in
the header-line and in the buffer.  But yeah, that was more an
experiment than anything.  I don't think I still use such code.
So, it's a "nice to have" but not if it breaks something else.

[ In another similar experiment, I tried to make an "in-buffer
  toolbar", but for that one using the same data was simply not an
  option, I needed a translation function.  ]

Seeing some of the crazy things some people do in fancy packages,
I wouldn't be completely surprised to hear that some people actually use
such things rather than just experiment with them.


        Stefan

Message #17 received at 76620 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: sbaugh <at> janestreet.com, 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Sun, 09 Mar 2025 11:50:20 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Spencer Baugh <sbaugh <at> janestreet.com>,  76620 <at> debbugs.gnu.org,
>   jonas <at> bernoul.li
> Date: Fri, 28 Feb 2025 10:44:00 -0500
> 
> >> The mode-line (and header-line) binding was added to button.el in
> >> 24fc9480399b2d018e8d85f34e9c5d8c327ce3bf to support using buttons in the
> >> mode-line and header-line.  I suggest that we should remove those
> >> bindings, in favor of some other way to use button.el in the mode-line
> >> or header-line.  Especially because, from grepping through ~400 popular
> >> packages (the ones installed at my site), I see no usage of buttons in
> >> the mode-line or header-line.
> >
> > Adding Stefan to the discussion.
> 
> FWIW, I've used code which used the same text (with buttons) in
> the header-line and in the buffer.  But yeah, that was more an
> experiment than anything.  I don't think I still use such code.
> So, it's a "nice to have" but not if it breaks something else.

So, on balance, you think we should revert commit
24fc9480399b2d018e8d85f34e9c5d8c327ce3bf?

Message #20 received at 76620 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Sun, 09 Mar 2025 18:25:24 -0400

>> FWIW, I've used code which used the same text (with buttons) in
>> the header-line and in the buffer.  But yeah, that was more an
>> experiment than anything.  I don't think I still use such code.
>> So, it's a "nice to have" but not if it breaks something else.
>
> So, on balance, you think we should revert commit
> 24fc9480399b2d018e8d85f34e9c5d8c327ce3bf?

I haven't looked at the problem closely enough to have an opinion, sorry.


        Stefan

Previous Next

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