From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Options menu is broken on CVS Date: Thu, 08 Sep 2005 22:33:45 +0300 Message-ID: References: <200509062007.04648.ismail@uludag.org.tr> <17181.65500.337376.386116@farnswood.snap.net.nz> <200509062349.18090.ismail@uludag.org.tr> <17182.8135.530028.132576@farnswood.snap.net.nz> <17183.25577.926363.814486@farnswood.snap.net.nz> <17183.48402.585456.467736@farnswood.snap.net.nz> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1126209402 22689 80.91.229.2 (8 Sep 2005 19:56:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 8 Sep 2005 19:56:42 +0000 (UTC) Cc: ismail@uludag.org.tr, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 08 21:56:33 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EDSTK-0003c5-PO for ged-emacs-devel@m.gmane.org; Thu, 08 Sep 2005 21:54:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EDSTK-0001Zy-4b for ged-emacs-devel@m.gmane.org; Thu, 08 Sep 2005 15:54:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EDSMg-00081l-PZ for emacs-devel@gnu.org; Thu, 08 Sep 2005 15:47:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EDSMV-0007vz-9x for emacs-devel@gnu.org; Thu, 08 Sep 2005 15:47:07 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EDSMS-0007jg-2w for emacs-devel@gnu.org; Thu, 08 Sep 2005 15:47:04 -0400 Original-Received: from [192.114.186.66] (helo=romy.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EDSE5-0006bJ-RK for emacs-devel@gnu.org; Thu, 08 Sep 2005 15:38:26 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-84-228-249-108.inter.net.il [84.228.249.108]) by romy.inter.net.il (MOS 3.5.8-GR) with ESMTP id CII04699 (AUTH halo1); Thu, 8 Sep 2005 22:33:43 +0300 (IDT) Original-To: Nick Roberts In-reply-to: <17183.48402.585456.467736@farnswood.snap.net.nz> (message from Nick Roberts on Thu, 8 Sep 2005 16:24:50 +1200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:42757 Archived-At: > From: Nick Roberts > Date: Thu, 8 Sep 2005 16:24:50 +1200 > Cc: ismail@uludag.org.tr, 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.