GNU bug report logs - #56155
29.0.50; Options menu, toggle menu items not updated

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56155 in the body.
You can then email your comments to 56155 AT debbugs.gnu.org in the normal way.

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

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Options menu, toggle menu items not updated
Date: Thu, 23 Jun 2022 11:09:16 +0200

In GNU Emacs 29.0.50 (build 5, aarch64-apple-darwin21.5.0, NS appkit-2113.50 Version 12.4 (Build 21F79))
 of 2022-06-21 built on Mini.fritz.box
Repository revision: b1af8c2c00aefe6aa554a468e65b6e07c9f14722

Recipe:

1. emacs -Q
2. From the Options menu, select Save Places in Files...
3. The toggle mark on the menu item remains unchanged

This seems to work for some menu items, but not for others.  Maybe NS
specific, I don't know.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 56155 <at> debbugs.gnu.org
Subject: Re: bug#56155: 29.0.50; Options menu, toggle menu items not updated
Date: Thu, 23 Jun 2022 13:15:13 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Thu, 23 Jun 2022 11:09:16 +0200
> 
> 1. emacs -Q
> 2. From the Options menu, select Save Places in Files...
> 3. The toggle mark on the menu item remains unchanged
> 
> This seems to work for some menu items, but not for others.  Maybe NS
> specific, I don't know.

I don't see it here, so it's probably NS specific, yes.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56155 <at> debbugs.gnu.org
Subject: Re: bug#56155: 29.0.50; Options menu, toggle menu items not updated
Date: Tue, 28 Jun 2022 14:06:22 +0200

[Message part 1 (text/plain, inline)]

> On 2022-06-23,, at 12:15 , Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Date: Thu, 23 Jun 2022 11:09:16 +0200
>> 
>> 1. emacs -Q
>> 2. From the Options menu, select Save Places in Files...
>> 3. The toggle mark on the menu item remains unchanged
>> 
>> This seems to work for some menu items, but not for others.  Maybe NS
>> specific, I don't know.
> 
> I don't see it here, so it's probably NS specific, yes.

I think I have it.

Some toggle menu items lead to a force-mode-line-update, others don't.  For instance, Options -> Hightlight Active Region does lead to a f-m-l-u, Options -> Enter Debugger on Error doesn't.  Consequently, the next redisplay after selecting the toggle either decides to call set_frame_menubar or not.  If it isn't run, the toggle marks are not updated in the menu.

What I don't know is if this can only be seen on macOS.  On macOS, one can select an option from the menu bar, re-open the Options menu and select another, wihout Emacs running anything in between the two selections that can itself set update_mode_lines.  If anything else sets update_mode_lines, the ill effect will not show up.  Just clicking in the text area runs a command...

A possible fix that works for me is attached.

Passing t to force-mode-line-update in the patch is be a bit brutal, perhaps.  I didn't want to play games after some brutal debugging.

[0001-Ensure-correct-toggle-menu-item-display.patch (application/octet-stream, attachment)]

[signature.asc (application/pgp-signature, attachment)]

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 56155 <at> debbugs.gnu.org
Subject: Re: bug#56155: 29.0.50; Options menu, toggle menu items not updated
Date: Tue, 28 Jun 2022 14:21:49 -0700

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> What I don't know is if this can only be seen on macOS.  On macOS, one can
> select an option from the menu bar, re-open the Options menu and select another,
> wihout Emacs running anything in between the two selections that can itself set
> update_mode_lines.  If anything else sets update_mode_lines, the ill effect will
> not show up.  Just clicking in the text area runs a command...

FWIW, I can reproduce the issue consistently on my macOS machine, but
not on GNU/Linux.

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 56155 <at> debbugs.gnu.org
Subject: Re: bug#56155: 29.0.50; Options menu, toggle menu items not updated
Date: Wed, 29 Jun 2022 01:38:10 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> What I don't know is if this can only be seen on macOS.  On macOS, one can
>> select an option from the menu bar, re-open the Options menu and select another,
>> wihout Emacs running anything in between the two selections that can itself set
>> update_mode_lines.  If anything else sets update_mode_lines, the ill effect will
>> not show up.  Just clicking in the text area runs a command...
>
> FWIW, I can reproduce the issue consistently on my macOS machine, but
> not on GNU/Linux.

That's interesting.  Could you put a breakpoint on that C function on
GNU/Linux to see if it's called, for example, when you close the menu?
That may be the key difference between macOS and the other operating
systems.  I don't have a GNU/Linux system at hand right now, but I can
investigate if needed.

(BTW, as an aside, getting a Lisp backtrace using LLDB on macOS is a bit
time-consuming because of all the manual steps to print the pointer
structures.  If I have time, I'd like to write an .lldbinit file with
LLDB commands to make this process much simpler, although I don't know
how many people are debugging Emacs using LLDB here.)

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 56155 <at> debbugs.gnu.org,
 Stefan Kangas <stefan <at> marxist.se>
Subject: Re: bug#56155: 29.0.50; Options menu, toggle menu items not updated
Date: Wed, 29 Jun 2022 07:32:52 +0200

[Message part 1 (text/plain, inline)]

> On 2022-06-29,, at 1:38 , Daniel Martín <mardani29 <at> yahoo.es> wrote:
> 
> Stefan Kangas <stefan <at> marxist.se> writes:
> 
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>> 
>>> What I don't know is if this can only be seen on macOS.  On macOS, one can
>>> select an option from the menu bar, re-open the Options menu and select another,
>>> wihout Emacs running anything in between the two selections that can itself set
>>> update_mode_lines.  If anything else sets update_mode_lines, the ill effect will
>>> not show up.  Just clicking in the text area runs a command...
>> 
>> FWIW, I can reproduce the issue consistently on my macOS machine, but
>> not on GNU/Linux.
> 
> That's interesting.  Could you put a breakpoint on that C function on
> GNU/Linux to see if it's called, for example, when you close the menu?
> That may be the key difference between macOS and the other operating
> systems.  I don't have a GNU/Linux system at hand right now, but I can
> investigate if needed.

I don't think it's necessary.  There are so many differences between toolkits in Emacs anyway, and f-m-l-u is portable in that sense.

> 
> (BTW, as an aside, getting a Lisp backtrace using LLDB on macOS is a bit
> time-consuming because of all the manual steps to print the pointer
> structures.  If I have time, I'd like to write an .lldbinit file with
> LLDB commands to make this process much simpler, although I don't know
> how many people are debugging Emacs using LLDB here.)

One people sits here.

GDB is currently not supported on macOS with Apple M1 says gdb-devel, and there is currently no one working on this that they know of.  So, I'm kind of stuck with LLDB for now.

If you get something working, please let me know.  The pressure of suffering is increasing, here.  I haven't got any further than a hello-world command so far.

[signature.asc (application/pgp-signature, attachment)]

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: 56155 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#56155: 29.0.50; Options menu, toggle menu items not updated
Date: Wed, 29 Jun 2022 08:04:14 +0200

[Message part 1 (text/plain, inline)]

Committed as 9c2b1d37e729f7af9e9661be7ece8348bae70ffa

I think the bug can be closed, but I don't see how I could do that.  Or maybe I can't and shouldn't, I don't know.

[signature.asc (application/pgp-signature, attachment)]

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

From: Po Lu <luangruo <at> yahoo.com>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 56155 <at> debbugs.gnu.org,
 Stefan Kangas <stefan <at> marxist.se>
Subject: Re: bug#56155: 29.0.50; Options menu, toggle menu items not updated
Date: Wed, 29 Jun 2022 14:12:11 +0800

Daniel Martín <mardani29 <at> yahoo.es> writes:

> That's interesting.  Could you put a breakpoint on that C function on
> GNU/Linux to see if it's called, for example, when you close the menu?
> That may be the key difference between macOS and the other operating
> systems.  I don't have a GNU/Linux system at hand right now, but I can
> investigate if needed.
>
> (BTW, as an aside, getting a Lisp backtrace using LLDB on macOS is a bit
> time-consuming because of all the manual steps to print the pointer
> structures.  If I have time, I'd like to write an .lldbinit file with
> LLDB commands to make this process much simpler, although I don't know
> how many people are debugging Emacs using LLDB here.)

The problem is well known (to me, at least.)  [EmacsMenu
menuNeedsUpdate:] only updates the menu bar if it was actually "dirtied"
by a previous "shallow" update (see set_frame_menubar in nsmenu.m), but
that never happens when only the value of a toggle item changes.

The other window systems intercept button presses on the menu bar, and
run Lisp in the keyboard loop to update the menu bar, before pushing the
button press event back onto the event queue.  But I can't figure out
how to do that on NS, and [EmacsMenu menuNeedsUpdate:] is called too
often to not utilize the "dirty" flag.

If someone does find out how to intercept events that will open the menu
bar, then most of the NS menu bar updating logic can be thrown out the
window, which will resolve not just this problem, but several others as
well.

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>,
 Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 56155 <at> debbugs.gnu.org,
 Stefan Kangas <stefan <at> marxist.se>
Subject: Re: bug#56155: 29.0.50; Options menu, toggle menu items not updated
Date: Wed, 29 Jun 2022 10:44:21 +0200

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:
>
> If someone does find out how to intercept events that will open the menu
> bar, then most of the NS menu bar updating logic can be thrown out the
> window, which will resolve not just this problem, but several others as
> well.

There is [EmacsMenu menuWillOpen:], whose implementation is empty right
now.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 56155 <at> debbugs.gnu.org,
 Stefan Kangas <stefan <at> marxist.se>
Subject: Re: bug#56155: 29.0.50; Options menu, toggle menu items not updated
Date: Wed, 29 Jun 2022 16:53:24 +0800

Daniel Martín <mardani29 <at> yahoo.es> writes:

> There is [EmacsMenu menuWillOpen:], whose implementation is empty right
> now.

It's not present (as in, not actually called) on GNUstep, and you aren't
supposed to perform long-running menu updates within it on Cocoa.

Updating the menu bar in Emacs takes somewhere between 50 to 300 ms
(this can depend on the current major and minor modes and GC), which is
too long.

The right thing would be to intercept and save the NSEvent that opened
the menu bar and generate a MENU_BAR_ACTIVATE_EVENT.  But I cannot
figure out how.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 56155 <at> debbugs.gnu.org
Subject: Re: bug#56155: 29.0.50; Options menu, toggle menu items not updated
Date: Wed, 29 Jun 2022 12:16:38 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> I think the bug can be closed, but I don't see how I could do that.
> Or maybe I can't and shouldn't, I don't know.

You can close the bug by sending a mail to 56155-close <at> debbugs.gnu.org,
but there still seems to be discussions about more general ways to fix
this...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 56155 <at> debbugs.gnu.org
Subject: Re: bug#56155: 29.0.50; Options menu, toggle menu items not updated
Date: Sat, 18 May 2024 08:31:12 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> I think the bug can be closed, but I don't see how I could do that.
>> Or maybe I can't and shouldn't, I don't know.
>
> You can close the bug by sending a mail to 56155-close <at> debbugs.gnu.org,
> but there still seems to be discussions about more general ways to fix
> this...

Nothing seems have come out the discussions, so I'm closing this.

Previous Next

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