Re: Options menu is broken on CVS

[Nick Roberts <nickrob@snap.net.nz>]

 > > I think this is the right fix.
 > 
 > Please describe the reasons why you think this is the right fix.

menu-updating-buffers is defined in syms_of_xmenu ().  Currently syms_of_xmenu
is only called in emacs.c if HAVE_MENUS is true.  menu-updating-buffers is
needed even if Emacs is configured without X (on GNU/Linux at least) but in
this case HAVE_MENUS is not defined.

xmenu.c is needed even HAVE_X_WINDOWS is not defined so I've moved it outside
the conditional requiring it.

 >                                                         (I'm
 > assuming you've read the discussions from 2004 that led to the
 > original changes.)

I might not have followed it all but your change seemed to cover Carbon Emacs
which it still does:

#ifndef HAVE_CARBON
XMENU_OBJ = xmenu.o
#endif

Now I've moved it outside #ifdef HAVE_X_WINDOWS you might need to add
another condition for when w32menu.o is used, I'm not sure. 

 > > Actually I think the problem was caused by Kim's change:
 > > 
 > > 2004-03-11  Kim F. Storm  <storm@cua.dk>
 > > 
 > > 	* Makefile.in:...
 > > 	(XMENU_OBJ) [HAVE_MENUS]: Move declaration to proper place.
 > 
 > That change was made for a reason as well: some problem on Carbon.  We
 > need to understand that problem, to be sure your change will not
 > reintroduce it.  I hope that the explanations I asked for above will
 > clarify this (I still didn't have time to re-read those past
 > discussions and retrace what problems we were trying to fix.)

I didn't find the discussion that led to this change.  It might have been
part of a general tidying process.

 > In addition, we need to explain why the OP says he started to see the
 > problem only recently.

I've tried to explain that in another post: more calls to menu-updating-frame
have been made in menu-bar.el (26/08/05).

 > > The preamble for xmenu.c says:
 > > 
 > > /* X Communication module for terminals which understand the X protocol.
 > > 
 > > but xmenu.c is more general than that and compiles without X.  Even its
 > > name is misleading (as with xdisp.c which also compiles without X).
 > 
 > That's history: xmenu.c was originally written for X, but then menu
 > support was added to the DOS port and later came tmm.  If you think
 > the name xmenu tricked Kim and myself into thinking it's only for X,
 > that was not the reason.

I don't have an opinion on whether you or Kim were tricked, just that the
description is misleading and that xmenu.c is needed even HAVE_X_WINDOWS is
not defined.

Nick