[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