bug#56155: 29.0.50; Options menu, toggle menu items not updated

bug#56155: 29.0.50; Options menu, toggle menu items not updated

[Gerd Möllmann]

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.

bug#56155: 29.0.50; Options menu, toggle menu items not updated

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@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.

bug#56155: 29.0.50; Options menu, toggle menu items not updated

[Gerd Möllmann]

[-- Attachment #1.1: Type: text/plain, Size: 1442 bytes --]



> On 2022-06-23,, at 12:15 , Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Gerd Möllmann <gerd.moellmann@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.



[-- Attachment #1.2: 0001-Ensure-correct-toggle-menu-item-display.patch --]
[-- Type: application/octet-stream, Size: 1337 bytes --]

From 625b0ea76630314d3c88b31ad9aab0d159d2873c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= <gerd@gnu.org>
Date: Tue, 28 Jun 2022 13:55:35 +0200
Subject: [PATCH] Ensure correct toggle menu item display

* lisp/menu-bar.el (menu-bar-make-toggle-command): Call
force-mode-line-update. (Bug#56155)
---
 lisp/menu-bar.el | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/menu-bar.el b/lisp/menu-bar.el
index 4a943d2528..92989fcfb2 100644
--- a/lisp/menu-bar.el
+++ b/lisp/menu-bar.el
@@ -749,7 +749,11 @@ menu-bar-make-toggle-command
        ;; interactively, because the purpose is to mark the variable as a
        ;; candidate for `Save Options', and we do not want to save options that
        ;; the user has already set explicitly in the init file.
-       (when interactively (customize-mark-as-set ',variable)))
+       (when interactively
+         (customize-mark-as-set ',variable))
+       ;; Toggle menu items must make sure that the menu is updated so
+       ;; that toggle marks are drawn in the right state.
+       (force-mode-line-update t))
      '(menu-item ,item-name ,command :help ,help
                  :button (:toggle . (and (default-boundp ',variable)
                                          (default-value ',variable)))
-- 
2.36.1


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 874 bytes --]

bug#56155: 29.0.50; Options menu, toggle menu items not updated

[Stefan Kangas]

Gerd Möllmann <gerd.moellmann@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.

bug#56155: 29.0.50; Options menu, toggle menu items not updated

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefan@marxist.se> writes:

> Gerd Möllmann <gerd.moellmann@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.)

bug#56155: 29.0.50; Options menu, toggle menu items not updated

[Gerd Möllmann]

[-- Attachment #1: Type: text/plain, Size: 1881 bytes --]



> On 2022-06-29,, at 1:38 , Daniel Martín <mardani29@yahoo.es> wrote:
> 
> Stefan Kangas <stefan@marxist.se> writes:
> 
>> Gerd Möllmann <gerd.moellmann@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.


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 874 bytes --]

bug#56155: 29.0.50; Options menu, toggle menu items not updated

[Gerd Möllmann]

[-- Attachment #1: Type: text/plain, Size: 173 bytes --]

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.

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 874 bytes --]

bug#56155: 29.0.50; Options menu, toggle menu items not updated

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Daniel Martín <mardani29@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.

bug#56155: 29.0.50; Options menu, toggle menu items not updated

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@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.

bug#56155: 29.0.50; Options menu, toggle menu items not updated

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Daniel Martín <mardani29@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.

bug#56155: 29.0.50; Options menu, toggle menu items not updated

[Lars Ingebrigtsen]

Gerd Möllmann <gerd.moellmann@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@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

bug#56155: 29.0.50; Options menu, toggle menu items not updated

[Gerd Möllmann]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Gerd Möllmann <gerd.moellmann@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@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.