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: Mattias EngdegÄrd <mattiase <at> acm.org>
To: Alan Third <alan <at> idiocy.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:06:15 +0100
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.

> 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?





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.