Re: scratch/ns/refactor 06d9e72 5/6: Move NS port toolbar handling to the window

[Alan Third <alan@idiocy.org>]

On Thu, Jun 24, 2021 at 03:58:40PM +0200, Robert Pluim wrote:
> >>>>> On Wed, 23 Jun 2021 17:06:12 +0100, Alan Third <alan@idiocy.org> said:
> 
>     Alan> On Wed, Jun 23, 2021 at 04:57:34PM +0200, Robert Pluim wrote:
>     >> >>>>> On Wed, 23 Jun 2021 15:27:42 +0100, Alan Third <alan@idiocy.org> said:
>     >> >> The second frame has the tool-bar disabled, but unlike master the
>     >> >> frame height is greater than the initial frame, and the frame title is
>     >> >> bigger as well, as if its height had not been adjusted after removing
>     >> >> the tool-bar.
>     >> 
>     Alan> What's happening is that the toolbar is set to be visible, but it has
>     Alan> nothing in it, so it shrinks to the toolbar's minimum height.
>     >> 
>     Alan> Can you please try the following, I think it should sort it:
>     >> 
>     >> Youʼre on a roll here Alan. That fixes it.
> 
>     Alan> I've pushed a fix if you want to give it a go.
> 
>     Alan> Plus another couple of patches which probably break something else.
> 
> I guess that using the menus being dodgy when displaying a
> tramp-visited buffer is normal? Emacs appears to be busy-looping, I
> can provide backtrace if you want.
> 
> I never use the menus, so itʼs not a big deal to me.

No, that's not normal... Well, it kind of is... For some reason tramp
+ menus causes problems. It may be because we have to run a whole
bunch of lisp stuff in the NS run loop while updating the contents of
the menus before opening them and that interacts in some way with the
tramp external processes' IO. I've no idea why.

It may ultimately make more sense to take a copy of the menu structure
when Emacs core updates the menus and then update them from that...

If you revert 99adf4b2af is the menu behaviour better, worse or the
same?
-- 
Alan Third