Re: menu-updating-frame is nil on X

[Eli Zaretskii]

> From: Juri Linkov <address@hidden>
> Cc: address@hidden
> Date: Thu, 10 Nov 2005 12:08:05 +0200
> 
> > Does the following patch give good results?
> >
> > Index: src/xmenu.c
> > ===================================================================
> > RCS file: /cvsroot/emacs/emacs/src/xmenu.c,v
> > retrieving revision 1.295
> > diff -u -r1.295 xmenu.c
> > --- src/xmenu.c     7 Aug 2005 12:33:19 -0000       1.295
> > +++ src/xmenu.c     9 Nov 2005 19:08:26 -0000
> > @@ -3498,6 +3498,7 @@
> >    /* Help display under X won't work because XMenuActivate contains
> >       a loop that doesn't give Emacs a chance to process it.  */
> >    menu_help_frame = f;
> > +  XSETFRAME (Vmenu_updating_frame, f);
> 
> It doesn't work.  Vmenu_updating_frame is nil initially on a new frame,
> because this change is in `xmenu_show', and in the non-toolkit version
> `xmenu_show' is called only after clicking on the menu bar.
> So initially some icons in the toolbar are disabled.  After the first
> mouse click on the menu bar, Vmenu_updating_frame gets a non-nil
> value, so icons on the toolbar become enabled.  But in any case,
> menu items in sub-menus on the menu bar are still disabled regardless
> of the value of Vmenu_updating_frame.

Thanks for testing and for this information.

> But I still doubt that setting of Vmenu_updating_frame is necessary.

Setting it could be useful in other contexts.  In any case, having a
variable that works only in a small number of Emacs configuration is
not a good idea, IMHO.

> My previous change (i.e. using `(or menu-updating-frame (selected-frame))')
> assumes that if `menu-updating-frame' is nil, this means that the menu
> frame is the same as the selected frame.

I'm not sure this is the right assumption.  I will think about this
problem some more and try to find a better solution.

Btw, if Vmenu_updating_frame is not set, it probably means that tmm
has trouble in the non-toolkit build.  Is that indeed so?