bug#31371: 26.1; Menu-bar stops working after search

[Alan Third <alan@idiocy.org>]

On Mon, May 07, 2018 at 02:48:16PM +1200, Nick Helm wrote:
> If this is the case, it should cause problems even by simply opening and
> closing the Help menu. And I think that's what we're seeing. From
> Emacs -Q, try opening and closing the Help menu (ignore search), then
> click between the visible frame and the desktop a few times. After a
> couple of tries, the frame cannot regain proper focus and the menu-bar
> doesn't operate at all.

I can’t replicate this. Nor your experiment with textedit in the other
email. I definitely see the issue you originally described, though.

> All of the delayed events and tracking stuff seems over-complicated and
> unnecessary. What am I missing? 

Apparently it was added because regenerating the menus calls lisp,
which is then able to call ns_select, however the code to regenerate
the menus is called from within the NS app loop within ns_select, so
we end up with the app loop running within the app loop via ns_select.

This isn’t allowed.

I notice all this code is cocoa only, though. Makes me wonder why
GNUstep is different. (The menus on GNUstep Emacs are awful, though,
they flicker constantly.)

I still don’t understand how this works, because I get the impression
from the code that the menus are generated when the user clicks on
them, but they clearly change when you switch windows or frame or
whatever.

So on the one hand it appears they’re updated within the NS app loop
as part of a response to the user clicking on the menu, but on the
other they’re generated outside the app loop by some lisp function or
something.

Maybe it’s both, in which case why?

Of course, none of this might be relevant to the help menu bug. I’m
quite lost at the moment.
-- 
Alan Third