bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alan Third
Subject: bug#32864: 26.1; menus don't work correctly in Mac OS Mojave
Date: Wed, 5 Jun 2019 22:27:19 +0100
User-agent: Mutt/1.12.0 (2019-05-25)

On Tue, Jun 04, 2019 at 11:08:10PM +0200, Mattias Engdegård wrote:
> 4 juni 2019 kl. 18.44 skrev Alan Third <alan@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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]