all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Third <alan@idiocy.org>
To: "Mattias Engdegård" <mattiase@acm.org>
Cc: Robert Pluim <rpluim@gmail.com>,
	omari@smileystation.com, 32864@debbugs.gnu.org, artemiog@mac.com,
	simon@simonscientific.com
Subject: bug#32864: 26.1; menus  don't work correctly in Mac OS Mojave
Date: Wed, 5 Jun 2019 22:27:19 +0100	[thread overview]
Message-ID: <20190605212719.GA39840@breton.holly.idiocy.org> (raw)
In-Reply-To: <D1E3B365-311D-4662-B286-4610950B1320@acm.org>

On Tue, Jun 04, 2019 at 11:08:10PM +0200, Mattias Engdegård wrote:
> 4 juni 2019 kl. 18.44 skrev Alan Third <alan@idiocy.org>:
> > 
> > It may also be the case that Emacs can try to run the event loop from
> > within elisp code as a matter of course.
> 
> I'm no Cocoa expert, but the docs explicitly state that recursively entering an event loop from an event handler is allowed.

Unfortunately I too am no expert. Perhaps I’ve misunderstood what was
going on.

> > The other solution I found is to rebuild the menu completely whenever
> > lisp updates it. This is simple enough to do but rebuilding the menus
> > takes something like 40‐70ms every time, as opposed to 1‐2ms to just
> > rebuild the top level, and it can do it up to three times per
> > keypress. I think it may also do it sometimes while scrolling. It
> > didn’t seem like a good idea to me. On the other hand I don’t remember
> > actually having much trouble with it.
> 
> Is the entire menu rebuilt every time some part of it changes, or
> are the changes segregated by drop-down menu? The Buffers menu
> probably sees a lot of traffic; it seems to be updated from
> menu-bar-update-hook, which fires a lot, even though most of the
> time the buffer list doesn't actually change.

IIRC set_frame_menubar is called with deep_p set to false and this
calls ns_update_menubar just recreating the top level.

When you click on a menu it does all the stuff you described
previously which ends up running ns_update_menubar with deep_p set to
true and this rebuilds the menu that was clicked on. I think. I don’t
think it rebuilds all menus.

> > If anyone has any other ideas I’d be happy to hear them.
> 
> The emacs-mac port, which seems to be an AppKit/Carbon hybrid (?),
> does not exhibit this menu glitch. I'm not sure exactly how it does
> this, but the general approach looks roughly similar. Maybe we could
> ask its author for advice.

Seems like a good idea.

Yamamoto‐san, I hope it’s OK to pull you into this discussion. Do you
have any thoughts on the issue described in:

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32864#38

-- 
Alan Third





  reply	other threads:[~2019-06-05 21:27 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-28 17:40 bug#32864: 26.1; menus don't work correctly in Mac OS Mojave Artemio González López
2018-09-28 19:40 ` Alan Third
     [not found]   ` <831B596E-F525-41BF-913D-4A976BABBBB0@mac.com>
2018-09-28 19:49     ` Alan Third
2018-10-01 13:12       ` Artemio González López
2018-10-04 18:35         ` Alan Third
2018-11-17 17:15 ` bug#32864: Run from Terminal Omari Norman
2018-11-17 17:19   ` Omari Norman
2019-02-08  8:15 ` bug#32864: 26.1; menus don't work correctly in Mac OS Mojave simonjgeorge
2019-02-11 22:21   ` Alan Third
2019-02-12 10:00     ` Robert Pluim
2019-05-28 18:31 ` Mattias Engdegård
2019-06-03 17:25   ` Mattias Engdegård
2019-06-03 18:20     ` Eli Zaretskii
2019-06-03 18:52       ` Mattias Engdegård
2019-06-04 16:44     ` Alan Third
2019-06-04 16:53       ` npostavs
2019-06-04 21:08       ` Mattias Engdegård
2019-06-05 21:27         ` Alan Third [this message]
2019-06-20  5:44 ` Tak Kunihiro
2020-01-10 12:01   ` pierrea
2020-05-01 16:30 ` bug#32864: menus don't work in Mac OS: see similar issue 24472 and workaround there Marc Herbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190605212719.GA39840@breton.holly.idiocy.org \
    --to=alan@idiocy.org \
    --cc=32864@debbugs.gnu.org \
    --cc=artemiog@mac.com \
    --cc=mattiase@acm.org \
    --cc=omari@smileystation.com \
    --cc=rpluim@gmail.com \
    --cc=simon@simonscientific.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.