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.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44333 in the body.
You can then email your comments to 44333 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#44333; Package emacs. (Fri, 30 Oct 2020 17:58:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Viktor Kharitonovich <viktor.kharitonovich <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Fri, 30 Oct 2020 17:58:02 GMT) Full text and rfc822 format available.

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

From: Viktor Kharitonovich <viktor.kharitonovich <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; macOS menu bar 2-clicks
Date: Fri, 30 Oct 2020 20:53:27 +0300
Hello,

On macOS 10.15.7 menu bar behave like a toggle switch. First click is
ignored. Then second click opens menu and everything works as expected. But
another next click on menu bar (not on an item) leads to hiding menu bar
and then again two clicks are needed for open.


In GNU Emacs 27.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G95))
of 2020-08-12 built on builder10-14.porkrind.org
Windowing system distributor 'Apple', version 10.3.1894
System Description:  Mac OS X 10.15.7

Recent messages:
uncompressing ido.el.gz...done
Searched 0/1 files
Searched 1/1 files
Quit
Mark set
current buffer is now: *unsent posting*
Making completion list... [2 times]
Quit
funcall-interactively: Buffer is read-only: #<buffer *5x5*>
Making completion list...

Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp' --with-modules'

Configured features:
NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES
THREADS JSON PDUMPER

Important settings:
  value of $LANG: en_BY.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  display-line-numbers-mode: t
  shell-dirtrack-mode: t
  recentf-mode: t
  ido-everywhere: t
  projectile-mode: t
  company-tng-mode: t
  global-company-mode: t
  company-mode: t
  override-global-mode: t
  delete-selection-mode: t
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/Users/hrls/.emacs.d/elpa/xref-1.0.3/xref hides /Applications/Emacs.app/Contents/Resources/lisp/progmodes/xref
/Users/hrls/.emacs.d/elpa/project-0.5.2/project hides /Applications/Emacs.app/Contents/Resources/lisp/progmodes/project
/Users/hrls/.emacs.d/elpa/flymake-1.0.9/flymake hides /Applications/Emacs.app/Contents/Resources/lisp/progmodes/flymake
/Users/hrls/.emacs.d/elpa/eldoc-1.11.0/eldoc hides /Applications/Emacs.app/Contents/Resources/lisp/emacs-lisp/eldoc

Features:
(shadow sort emacsbug sendmail 5x5 mail-extr ielm cl-print debug
display-line-numbers vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs vc-dir
ewoc vc vc-dispatcher haskell-doc inf-haskell haskell-decl-scan shell
pcomplete haskell haskell-completions haskell-load haskell-commands
highlight-uses-mode haskell-modules haskell-sandbox
haskell-navigate-imports haskell-repl haskell-svg haskell-collapse
hideshow haskell-debug haskell-interactive-mode
haskell-presentation-mode haskell-compile haskell-hoogle haskell-process
haskell-session haskell-mode haskell-cabal haskell-utils
haskell-font-lock haskell-indentation haskell-string
haskell-sort-imports haskell-lexeme haskell-align-imports
haskell-complete-module haskell-ghc-support flymake-proc flymake
warnings dabbrev haskell-customize deeper-blue-theme dichromacy-theme
leuven-theme light-blue-theme manoj-dark-theme misterioso-theme
tango-dark-theme tango-theme tsdh-dark-theme tsdh-light-theme
wheatgrass-theme whiteboard-theme tango-plus-theme recentf tree-widget
flatland-theme cus-theme autoload cus-edit cus-start cus-load wid-edit
lisp-mnt mm-archive message format-spec rfc822 mml mml-sec epa derived
epg gnus-util rmail rmail-loaddefs text-property-search mailabbrev
gmm-utils mailheader mm-decode mm-bodies mm-encode mail-utils misearch
multi-isearch gnutls network-stream url-http mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm rmc puny url-cache
url-auth url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util mailcap epg-config finder-inf dired-aux
dired-x vc-git diff-mode cargo cargo-process markdown-mode color
noutline outline flycheck time-date pp jka-compr company-oddmuse
company-keywords company-etags etags fileloop generator xref project
company-gtags company-dabbrev-code company-dabbrev company-files
company-clang company-capf company-cmake company-semantic
company-template company-bbdb omnitab my-packages helpful imenu trace
edebug backtrace info-look advice find-func f dash-functional help-fns
radix-tree elisp-refs s dash ido hydra lv projectile grep compile comint
ansi-color ibuf-ext rust-mode rx thingatpt company-tng company pcase
ace-window avy ring exec-path-from-shell diminish delight cl-extra
help-mode use-package use-package-ensure use-package-delight
use-package-diminish use-package-bind-key bind-key easy-mmode
use-package-core edmacro kmacro wm suwayyah server wombat-theme dired
dired-loaddefs ibuffer ibuffer-loaddefs delsel paren info package
easymenu browse-url url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
threads kqueue cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 417887 486947)
(symbols 48 34423 1)
(strings 32 142378 89905)
(string-bytes 1 3608995)
(vectors 16 44990)
(vector-slots 8 604398 45426)
(floats 8 351 405)
(intervals 56 2562 282)
(buffers 1000 43))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44333; Package emacs. (Fri, 30 Oct 2020 22:43:01 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Viktor Kharitonovich <viktor.kharitonovich <at> gmail.com>
Cc: 44333 <at> debbugs.gnu.org
Subject: Re: bug#44333: 27.1; macOS menu bar 2-clicks
Date: Fri, 30 Oct 2020 22:42:17 +0000
On Fri, Oct 30, 2020 at 08:53:27PM +0300, Viktor Kharitonovich wrote:
> Hello,
> 
> On macOS 10.15.7 menu bar behave like a toggle switch. First click is
> ignored. Then second click opens menu and everything works as expected. But
> another next click on menu bar (not on an item) leads to hiding menu bar
> and then again two clicks are needed for open.
> 
> 
> In GNU Emacs 27.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G95))
> of 2020-08-12 built on builder10-14.porkrind.org
> Windowing system distributor 'Apple', version 10.3.1894
> System Description:  Mac OS X 10.15.7

This looks like an emacsformacosx.com build.

IIRC you need to add Ruby to the accessibility permissions group in
the privacy settings.

I'm a little hazy on what needs done here, but if someone who
understands this could write it up for PROBLEMS I'd appreciate it.
-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44333; Package emacs. (Sat, 31 Oct 2020 14:09:02 GMT) Full text and rfc822 format available.

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

From: Mattias Engdegård <mattiase <at> acm.org>
To: Alan Third <alan <at> idiocy.org>,
 Viktor Kharitonovich <viktor.kharitonovich <at> gmail.com>
Cc: 44333 <at> debbugs.gnu.org
Subject: Re: bug#44333: 27.1; macOS menu bar 2-clicks 
Date: Sat, 31 Oct 2020 15:08:14 +0100
> IIRC you need to add Ruby to the accessibility permissions group in
> the privacy settings.

What are the privacy/security implications of doing so?

Since the Mac port reportedly doesn't suffer from this problem, could we learn from it and do the same?

(There should be a previous bug report.)





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44333; Package emacs. (Sat, 31 Oct 2020 15:02:02 GMT) Full text and rfc822 format available.

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

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: Re: bug#44333: 27.1; macOS menu bar 2-clicks
Date: Sat, 31 Oct 2020 15:01:01 +0000
On Sat, Oct 31, 2020 at 03:08:14PM +0100, Mattias Engdegård wrote:
> > IIRC you need to add Ruby to the accessibility permissions group in
> > the privacy settings.
> 
> What are the privacy/security implications of doing so?

I have no idea.

> Since the Mac port reportedly doesn't suffer from this problem,
> could we learn from it and do the same?

IIRC the problem is due to the reposting of the menu click event so
the menu can be populated when lisp is running. The Mac port doesn't
have this problem most probably because it's a completely different
architecture but it has the GUI and lisp parts split into two separate
threads which is one way I can see of fixing this.

I'm not keen on doing the complete overhaul required because I'll
likely introduce more bugs than I'll fix, and I'm pretty sure my next
computer isn't going to be a Mac. Introducing lots of bugs then
running doesn't seem like a good approach.

If anyone else has a simpler solution I'd love to hear it.
-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44333; Package emacs. (Sun, 01 Nov 2020 10:51:01 GMT) Full text and rfc822 format available.

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

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: Re: bug#44333: 27.1; macOS menu bar 2-clicks 
Date: Sun, 1 Nov 2020 11:50:32 +0100
[Message part 1 (text/plain, inline)]
31 okt. 2020 kl. 16.01 skrev Alan Third <alan <at> idiocy.org>:

> IIRC the problem is due to the reposting of the menu click event so
> the menu can be populated when lisp is running. The Mac port doesn't
> have this problem most probably because it's a completely different
> architecture but it has the GUI and lisp parts split into two separate
> threads which is one way I can see of fixing this.

Last time I looked it seemed that the Mac port actually did synthesise events but used some other means (Carbon?), but I may be wrong.


> If anyone else has a simpler solution I'd love to hear it.

Maybe we are overthinking it. I don't think the Cocoa event loop really is running in a different thread. Anecdotal evidence (printf!) indicates that it isn't.

(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32864#38 has a previous investigation into the matter.)

I just did the simplest thing possible and it works (with a slight latency at times, but perhaps tolerable). I'd like to know what's wrong with running Lisp in the event loop. It does appear safe to me.

[macos-1-click-menu-bar.diff (application/octet-stream, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44333; Package emacs. (Sun, 01 Nov 2020 17:29:01 GMT) Full text and rfc822 format available.

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

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: Re: bug#44333: 27.1; macOS menu bar 2-clicks
Date: Sun, 1 Nov 2020 17:28:43 +0000
On Sun, Nov 01, 2020 at 11:50:32AM +0100, Mattias Engdegård wrote:
> > If anyone else has a simpler solution I'd love to hear it.
> 
> Maybe we are overthinking it. I don't think the Cocoa event loop
> really is running in a different thread. Anecdotal evidence
> (printf!) indicates that it isn't.

On the Mac port? It certainly isn't on the NS port... I don't think
the Mac port even really uses the Cocoa event loop, although I could
easily be wrong.

> (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32864#38 has a
> previous investigation into the matter.)
> 
> I just did the simplest thing possible and it works (with a slight
> latency at times, but perhaps tolerable). I'd like to know what's
> wrong with running Lisp in the event loop. It does appear safe to
> me.

We used to have a *lot* of crashes that were related to the event loop
and lisp and so on, but if you're confident it isn't a problem feel
free to propose a patch and we can give it a go on master.

-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44333; Package emacs. (Wed, 23 Dec 2020 20:35:01 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Mattias Engdegård <mattiase <at> acm.org>,
 44333 <at> debbugs.gnu.org,
 Viktor Kharitonovich <viktor.kharitonovich <at> gmail.com>
Subject: Re: bug#44333: 27.1; macOS menu bar 2-clicks
Date: Wed, 23 Dec 2020 20:33:57 +0000
[Message part 1 (text/plain, inline)]
On Sun, Nov 01, 2020 at 05:28:43PM +0000, Alan Third wrote:
> On Sun, Nov 01, 2020 at 11:50:32AM +0100, Mattias Engdegård wrote:
> > > If anyone else has a simpler solution I'd love to hear it.
> > 
> > Maybe we are overthinking it. I don't think the Cocoa event loop
> > really is running in a different thread. Anecdotal evidence
> > (printf!) indicates that it isn't.
> 
> On the Mac port? It certainly isn't on the NS port... I don't think
> the Mac port even really uses the Cocoa event loop, although I could
> easily be wrong.
> 
> > (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32864#38 has a
> > previous investigation into the matter.)
> > 
> > I just did the simplest thing possible and it works (with a slight
> > latency at times, but perhaps tolerable). I'd like to know what's
> > wrong with running Lisp in the event loop. It does appear safe to
> > me.
> 
> We used to have a *lot* of crashes that were related to the event loop
> and lisp and so on, but if you're confident it isn't a problem feel
> free to propose a patch and we can give it a go on master.

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.

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.
-- 
Alan Third
[0001-Remove-NS-menu-synthesized-events-bug-44333.patch (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44333; Package emacs. (Fri, 25 Dec 2020 16:07:02 GMT) Full text and rfc822 format available.

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

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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44333; Package emacs. (Fri, 25 Dec 2020 17:28:02 GMT) Full text and rfc822 format available.

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

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: Re: 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44333; Package emacs. (Fri, 25 Dec 2020 19:21:02 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Mattias Engdegård <mattiase <at> acm.org>,
 44333 <at> debbugs.gnu.org,
 Viktor Kharitonovich <viktor.kharitonovich <at> gmail.com>
Subject: Re: bug#44333: 27.1; macOS menu bar 2-clicks
Date: Fri, 25 Dec 2020 19:20:23 +0000
On Fri, Dec 25, 2020 at 05:26:49PM +0000, Alan Third wrote:
> 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.

I've had a look through it, and I've noticed that most of the work
appears to be building a tree of widget_value structs. A quick look at
xmenu.c and w32menu.c leaves me with the impression that they have
almost identical code for that part, but for some reason the NS port
is different (and is full of "FIXME: this is broken" comments).

So I suppose the first thing to do should be to align the NS code with
the other terminals, and see if that improves things.
-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44333; Package emacs. (Fri, 25 Dec 2020 22:30:01 GMT) Full text and rfc822 format available.

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

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: Re: bug#44333: 27.1; macOS menu bar 2-clicks
Date: Fri, 25 Dec 2020 23:28:56 +0100
25 dec. 2020 kl. 20.20 skrev Alan Third <alan <at> idiocy.org>:
> 
> On Fri, Dec 25, 2020 at 05:26:49PM +0000, Alan Third wrote:
>> 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.
> 
> I've had a look through it, and I've noticed that most of the work
> appears to be building a tree of widget_value structs. A quick look at
> xmenu.c and w32menu.c leaves me with the impression that they have
> almost identical code for that part, but for some reason the NS port
> is different (and is full of "FIXME: this is broken" comments).
> 
> So I suppose the first thing to do should be to align the NS code with
> the other terminals, and see if that improves things.

Probably. When the code suffers from one of its slow spells, the time is apparently spent in the calls to parse_single_submenu, and from there... single_keymap_panes, I think. Didn't dig deeper after that.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44333; Package emacs. (Sat, 26 Dec 2020 17:09:02 GMT) Full text and rfc822 format available.

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

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: Re: bug#44333: 27.1; macOS menu bar 2-clicks
Date: Sat, 26 Dec 2020 17:07:58 +0000
[Message part 1 (text/plain, inline)]
On Fri, Dec 25, 2020 at 11:28:56PM +0100, Mattias Engdegård wrote:
> 25 dec. 2020 kl. 20.20 skrev Alan Third <alan <at> idiocy.org>:
> > 
> > On Fri, Dec 25, 2020 at 05:26:49PM +0000, Alan Third wrote:
> >> 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.
> > 
> > I've had a look through it, and I've noticed that most of the work
> > appears to be building a tree of widget_value structs. A quick look at
> > xmenu.c and w32menu.c leaves me with the impression that they have
> > almost identical code for that part, but for some reason the NS port
> > is different (and is full of "FIXME: this is broken" comments).
> > 
> > So I suppose the first thing to do should be to align the NS code with
> > the other terminals, and see if that improves things.
> 
> Probably. When the code suffers from one of its slow spells, the
> time is apparently spent in the calls to parse_single_submenu, and
> from there... single_keymap_panes, I think. Didn't dig deeper after
> that.

Does the attached seem any better? It appears to me like the first
click on a menu is slightly faster (but that may be my imagination),
and subsequent menus are instant.
-- 
Alan Third
[v2-0001-Remove-NS-menu-synthesized-events-bug-44333.patch (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44333; Package emacs. (Sat, 26 Dec 2020 17:43:01 GMT) Full text and rfc822 format available.

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

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: Re: bug#44333: 27.1; macOS menu bar 2-clicks
Date: Sat, 26 Dec 2020 18:42:18 +0100
26 dec. 2020 kl. 18.07 skrev Alan Third <alan <at> idiocy.org>:

> Does the attached seem any better? It appears to me like the first
> click on a menu is slightly faster (but that may be my imagination),
> and subsequent menus are instant.

Not bad at all! Slow spells all gone as far as I can tell. Ship it!

Next up, import the hacks from the Mac port that right-justifies keyboard shortcuts in the menus?





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44333; Package emacs. (Sat, 26 Dec 2020 21:53:01 GMT) Full text and rfc822 format available.

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

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: Re: bug#44333: 27.1; macOS menu bar 2-clicks
Date: Sat, 26 Dec 2020 21:52:10 +0000
On Sat, Dec 26, 2020 at 06:42:18PM +0100, Mattias Engdegård wrote:
> 26 dec. 2020 kl. 18.07 skrev Alan Third <alan <at> idiocy.org>:
> 
> > Does the attached seem any better? It appears to me like the first
> > click on a menu is slightly faster (but that may be my imagination),
> > and subsequent menus are instant.
> 
> Not bad at all! Slow spells all gone as far as I can tell. Ship it!

Cool. I might do some further tidying up. I'll see how I feel.

> Next up, import the hacks from the Mac port that right-justifies
> keyboard shortcuts in the menus?

It doesn't actually right align them, but they're certainly neater.
It's actually almost possible to copy the Mac port code in verbatim,
the NS port's code is based on it after all, but I feel it may be
neater to use a custom view for the NSMenuItems. That would give us
complete control over the layout.

Of course, someone would have to actually do that work...
-- 
Alan Third




Reply sent to Alan Third <alan <at> idiocy.org>:
You have taken responsibility. (Sun, 27 Dec 2020 16:58:01 GMT) Full text and rfc822 format available.

Notification sent to Viktor Kharitonovich <viktor.kharitonovich <at> gmail.com>:
bug acknowledged by developer. (Sun, 27 Dec 2020 16:58:02 GMT) Full text and rfc822 format available.

Message #49 received at 44333-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Mattias Engdegård <mattiase <at> acm.org>,
 44333-done <at> debbugs.gnu.org,
 Viktor Kharitonovich <viktor.kharitonovich <at> gmail.com>
Subject: Re: bug#44333: 27.1; macOS menu bar 2-clicks
Date: Sun, 27 Dec 2020 16:56:59 +0000
On Sat, Dec 26, 2020 at 09:52:10PM +0000, Alan Third wrote:
> On Sat, Dec 26, 2020 at 06:42:18PM +0100, Mattias Engdegård wrote:
> > 26 dec. 2020 kl. 18.07 skrev Alan Third <alan <at> idiocy.org>:
> > 
> > > Does the attached seem any better? It appears to me like the first
> > > click on a menu is slightly faster (but that may be my imagination),
> > > and subsequent menus are instant.
> > 
> > Not bad at all! Slow spells all gone as far as I can tell. Ship it!
> 
> Cool. I might do some further tidying up. I'll see how I feel.

I've pushed a modified version of this code to master.

It doesn't work on GNUstep, but GNUstep menus have been broken for a
while anyway, and I don't know what's wrong with them.

-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44333; Package emacs. (Sun, 27 Dec 2020 17:15:02 GMT) Full text and rfc822 format available.

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

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: Re: bug#44333: 27.1; macOS menu bar 2-clicks 
Date: Sun, 27 Dec 2020 18:14:25 +0100
[Message part 1 (text/plain, inline)]
26 dec. 2020 kl. 22.52 skrev Alan Third <alan <at> idiocy.org>:

> It's actually almost possible to copy the Mac port code in verbatim,
> the NS port's code is based on it after all, but I feel it may be
> neater to use a custom view for the NSMenuItems. That would give us
> complete control over the layout.

We should, but because I was lazy and impatient, I wrote the attached (terrible) hack just to see what right-justification would look like.

The right margin is slightly ragged because I'm using plain spaces to offset the key binding from the menu text, but I still think it's better than what we have now. I tried using U+2009 THIN SPACE and even U+200A HAIR SPACE instead but somehow the result became worse; no doubt a silly mistake somewhere.

I also removed the special hack for s- bindings because it broke the nice alignment. If we want, we could translate modifiers into the standard symbols (⌘, ⌃, ⇧ and ⌥) depending on these are assigned, or just keep using the Emacs notation. We could also translate <right> into → and so on.

[right-justify-keys.diff (application/octet-stream, attachment)]

Forcibly Merged 24719 32864 34213 44333. Request was from Mattias Engdegård <mattiase <at> acm.org> to control <at> debbugs.gnu.org. (Mon, 28 Dec 2020 14:07:01 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 26 Jan 2021 12:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 63 days ago.

Previous Next


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