emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: menu-updating-frame is nil on X


From: Eli Zaretskii
Subject: Re: menu-updating-frame is nil on X
Date: Wed, 09 Nov 2005 01:07:46 +0200

> From: Juri Linkov <address@hidden>
> Cc: address@hidden
> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]