Subject: bug#32864: 26.1; menus don't work correctly in Mac OS Mojave

From: Mattias Engdegård <[email-masked]>
Date: Tue, 4 Jun 2019 23:08:10 +0200

4 juni 2019 kl. 18.44 skrev Alan Third <[email-masked]>:
> 
> It may also be the case that Emacs can try to run the event loop from
> within elisp code as a matter of course.

I'm no Cocoa expert, but the docs explicitly state that recursively entering an event loop from an event handler is allowed.

> The other solution I found is to rebuild the menu completely whenever
> lisp updates it. This is simple enough to do but rebuilding the menus
> takes something like 40‐70ms every time, as opposed to 1‐2ms to just
> rebuild the top level, and it can do it up to three times per
> keypress. I think it may also do it sometimes while scrolling. It
> didn’t seem like a good idea to me. On the other hand I don’t remember
> actually having much trouble with it.

Is the entire menu rebuilt every time some part of it changes, or are the changes segregated by drop-down menu?
The Buffers menu probably sees a lot of traffic; it seems to be updated from menu-bar-update-hook, which fires a lot, even though most of the time the buffer list doesn't actually change.

It's probably a bad idea to add a latency of 40-70 ms several times per key press in any case.

> If anyone has any other ideas I’d be happy to hear them.

The emacs-mac port, which seems to be an AppKit/Carbon hybrid (?), does not exhibit this menu glitch. I'm not sure exactly how it does this, but the general approach looks roughly similar. Maybe we could ask its author for advice.