GNU bug report logs - #32864
26.1; menus don't work correctly in Mac OS Mojave

Previous Next

Package: emacs;

Reported by: Artemio González López <artemiog <at> mac.com>

Date: Fri, 28 Sep 2018 17:43:01 UTC

Severity: normal

Merged with 24719, 34213, 44333

Found in versions 26.0.50, 26.1, 27.0.50, 27.1

Done: Alan Third <alan <at> idiocy.org>

Bug is archived. No further changes may be made.

Full log


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

From: Alan Third <alan <at> idiocy.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Robert Pluim <rpluim <at> gmail.com>, omari <at> smileystation.com,
 32864 <at> debbugs.gnu.org, artemiog <at> mac.com,
 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, simon <at> simonscientific.com
Subject: Re: bug#32864: 26.1; menus  don't work correctly in Mac OS Mojave
Date: Wed, 5 Jun 2019 22:27:19 +0100
On Tue, Jun 04, 2019 at 11:08:10PM +0200, Mattias Engdegård wrote:
> 4 juni 2019 kl. 18.44 skrev Alan Third <alan <at> idiocy.org>:
> > 
> > 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.

Unfortunately I too am no expert. Perhaps I’ve misunderstood what was
going on.

> > 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.

IIRC set_frame_menubar is called with deep_p set to false and this
calls ns_update_menubar just recreating the top level.

When you click on a menu it does all the stuff you described
previously which ends up running ns_update_menubar with deep_p set to
true and this rebuilds the menu that was clicked on. I think. I don’t
think it rebuilds all menus.

> > 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.

Seems like a good idea.

Yamamoto‐san, I hope it’s OK to pull you into this discussion. Do you
have any thoughts on the issue described in:

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32864#38

-- 
Alan Third




This bug report was last modified 4 years and 199 days ago.

Previous Next


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