GNU bug report logs - #31371
26.1; [macOS] Menu-bar stops working after search

Previous Next

Package: emacs;

Reported by: Nick Helm <nick <at> tenpoint.co.nz>

Date: Sat, 5 May 2018 14:17:03 UTC

Severity: normal

Tags: patch

Found in version 26.1

Fixed in version 27.1

Done: Stefan Kangas <stefan <at> marxist.se>

Bug is archived. No further changes may be made.

Full log


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

From: Alan Third <alan <at> idiocy.org>
To: Nick Helm <nick <at> tenpoint.co.nz>
Cc: 31371 <at> debbugs.gnu.org
Subject: Re: bug#31371: 26.1; Menu-bar stops working after search
Date: Tue, 8 May 2018 22:40:24 +0100
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




This bug report was last modified 5 years and 139 days ago.

Previous Next


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