> From: Juri Linkov <[EMAIL PROTECTED]> > Cc: emacs-pretest-bug@gnu.org > Date: Tue, 08 Nov 2005 14:43:43 +0200 > > >> In Emacs configured with '--with-x-toolkit=no' on i686-pc-linux-gnu > >> and run with `emacs -Q', `menu-updating-frame' is nil. This causes > >> some menu items to be permanently disabled due to the condition in > >> `menu-bar-menu-frame-live-and-visible-p' where `(display-multi-frame-p)' > >> returns `t'. > > > > The theory behind that code was that menu-updating-frame cannot > > possibly be nil on a display that supports multiple frames visible at > > the same time. How come the non-toolkit version doesn't bind > > menu-updating-frame to something non-nil? Can you please investigate? > > Emacs built without a X toolkit doesn't have a separate frame for > the menu bar.
I think we are miscommunicating: I didn't mean to say that the menu bar is a separate frame, I meant to say that a windowed Emacs session sets menu-updating-frame to the frame from which the menu was invoked. In xmenu.c the function set_frame_menubar binds menu-updating-frame to the frame passed to it as argument. Could you please look and see why this isn't working as intended? > What do you think about the following change? Would it work in all cases? Without a clear understanding what happens in the non-toolkit case, I cannot really answer that. And I don't like working around a problem I don't understand. Using selected-frame is okay for the case of a character terminal, since there we _know_ that the selected frame is the one which invoked the menu (usually via tmm). But that logic doesn't work on X. _______________________________________________ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
