GNU bug report logs - #44333
27.1; macOS menu bar 2-clicks

Previous Next

Package: emacs;

Reported by: Viktor Kharitonovich <viktor.kharitonovich <at> gmail.com>

Date: Fri, 30 Oct 2020 17:58:02 UTC

Severity: normal

Merged with 24719, 32864, 34213

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


View this message in rfc822 format

From: Alan Third <alan <at> idiocy.org>
To: Mattias EngdegÄrd <mattiase <at> acm.org>
Cc: 44333 <at> debbugs.gnu.org, Viktor Kharitonovich <viktor.kharitonovich <at> gmail.com>
Subject: bug#44333: 27.1; macOS menu bar 2-clicks
Date: Fri, 25 Dec 2020 17:26:49 +0000
On Fri, Dec 25, 2020 at 05:06:15PM +0100, Mattias EngdegÄrd wrote:
> 23 dec. 2020 kl. 21.33 skrev Alan Third <alan <at> idiocy.org>:
> 
> > OK, I've had a go at this and tried removing EVERYTHING related to the
> > delayed menu stuff and, as you say, it seems fine, but I barely ever
> > use the menus, so I could be missing something.
> 
> Thank you, I tried exactly the same thing. While it works, there are
> annoying delays in dropping down the menus -- sometimes they come
> down immediately, but more often than not I get a delay of 100-300
> ms. Do you experience them too?
> 
> In any case, it's a lot better than the previous double-clutch
> menus. I rarely use the menus either but partly because they were so
> annoying; I find them useful for discovering functionality and keys
> in packages. Getting rid of the delays would be nice, though.

I don't see how the delays can be new as the menus would have to be
recalculated under the old code anyway...

It is quite noticeable, though...

I notice this in the Apple docs[1]:

    If populating the menu will take a long time, implement
    numberOfItemsInMenu: and menu:updateItem:atIndex:shouldCancel:
    instead.

I wonder if that's possible for us. ns_update_menubar is a big,
complicated function that I've not been over in depth to work out what
it's doing, so I don't know if it would be practical to break it up
like I suspect using those two methods would require.

> > For the record, the menu code (or maybe it's the toolbar, but I
> > suspect the menus) kills GNUstep builds stone dead as soon as you try
> > typing anything. It looks from the debugger like Emacs is still
> > running, but it just won't update the screen. Turning off the menus
> > appears to fix it.
> 
> Maybe we could make the change conditional on GNUstep?

Sorry, I was unclear. This is an older problem. I'm not sure when it
was introduced.

[1] https://developer.apple.com/documentation/appkit/nsmenudelegate/1518235-menuneedsupdate?language=objc
-- 
Alan Third




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

Previous Next


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