[Top][All Lists]

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

Re: Options menu is broken on CVS

From: Nick Roberts
Subject: Re: Options menu is broken on CVS
Date: Sat, 10 Sep 2005 11:07:25 +1200

 > HAVE_MENUS means menu support on the C level.  tmm doesn't do that, it
 > _emulates_ menus on the Lisp level.

OK.  I see now.

 > > However, xmenu.c _does_ compile without
 > > X11 headers and libraries, otherwise you couldn't make a non-X build with
 > > it.
 > If the headers and libraries are present on the system, you could
 > build such a version allright.

xmenu.c compiles without X libraries (--without-x doesn't link to them) but
now I think that the non-X build on Unix and GNU systems doesn't define
HAVE_MENUS because it shouldn't need xmenu.c

 > >  > Meanwhile, I don't think we should apply your suggested changes, since
 > >  > compiling xmenu.c on a system without X headers and libraries might
 > >  > fail due to unresolved externals.
 > > 
 > > It solved the OP's problem.  I suggest that we do apply it as thats the
 > > only way to test it.  If it is wrong, I am sure we will hear about it
 > > shortly.
 > No need, as I fixed that differently.

Yes, I think your change is generally right, non-X builds don't seem to use
menu-updating-frame (it's always nil if defined).

However you have missed some references to menu-updating-frame.  For example
F10->f doesn't work beacuse of:

(put 'dired 'menu-enable
     '(not (window-minibuffer-p (frame-selected-window menu-updating-frame))))

You might also need display-multi-frame-p in kill-this-buffer-enabled-p.


reply via email to

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