> From: Nick Roberts <[EMAIL PROTECTED]> > Date: Thu, 8 Sep 2005 16:24:50 +1200 > Cc: [EMAIL PROTECTED], emacs-devel@gnu.org > > > > 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.
Thanks. However, this is not what I asked; the reasons why symbols defined in syms_of_xmenu are void unless xmenu.o is linked in are perfectly clear. Sorry for not being more clear. What I meant is to have an explanation why your change solves the same problem which caused Kim and myself to place XMENU_OBJ in a different place, without breaking other ports and configurations. That would require to understand the original problem, which had something to do with Carbon. > 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. That's exactly the breakage I was afraid of. > > 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. No, it was to solve a very specific issue with Carbon. Okay, I will try to dig into this over the weekend. Solution for non-X builds will have to wait until then. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel