From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.devel Subject: Re: GC garbles menu items Date: Thu, 22 Dec 2005 00:47:39 -0500 Message-ID: References: <4390611E.3040500@swipnet.se> <4391A9CE.6090706@swipnet.se> <87acffdnrg.fsf@jurta.org> <439D501F.8060609@swipnet.se> <87pso1bdrb.fsf@jurta.org> <43A08825.8070704@swipnet.se> <87k6e6myqw.fsf@jurta.org> <873bkte58s.fsf@jurta.org> <87ek4cngkz.fsf_-_@jurta.org> <87psnrmwm8.fsf@jurta.org> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1135230577 9503 80.91.229.2 (22 Dec 2005 05:49:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Dec 2005 05:49:37 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 22 06:49:36 2005 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EpJKa-0005VE-JM for ged-emacs-devel@m.gmane.org; Thu, 22 Dec 2005 06:49:36 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EpJLZ-0007BS-Hv for ged-emacs-devel@m.gmane.org; Thu, 22 Dec 2005 00:50:37 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EpJJk-0005tu-Oa for emacs-devel@gnu.org; Thu, 22 Dec 2005 00:48:44 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EpJJk-0005t6-08 for emacs-devel@gnu.org; Thu, 22 Dec 2005 00:48:44 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EpJJj-0005sQ-LB for emacs-devel@gnu.org; Thu, 22 Dec 2005 00:48:43 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EpJIn-0001JI-Th for emacs-devel@gnu.org; Thu, 22 Dec 2005 00:47:46 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1EpJIh-0006bG-JO; Thu, 22 Dec 2005 00:47:39 -0500 Original-To: Juri Linkov In-reply-to: <87psnrmwm8.fsf@jurta.org> (message from Juri Linkov on Tue, 20 Dec 2005 23:54:07 +0200) 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:48205 Archived-At: Is it possible to prevent relocation of the strings in GC for the time while the menu is up? There is no feature to stop GC from relocating strings. Adding one would be a much more radical and risky change. I don't want to do that now, and perhaps not later. What would be easier to do is turn off GC while the menu is up. There is already a way to do that: call inhibit_garbage_collection. Does this patch fix it? *** xmenu.c 21 Dec 2005 19:38:13 -0500 1.297 --- xmenu.c 22 Dec 2005 00:36:37 -0500 *************** *** 3343,3348 **** --- 3343,3350 ---- return Qnil; } + inhibit_garbage_collection (); + #ifdef HAVE_X_WINDOWS /* Adjust coordinates to relative to the outer (window manager) window. */ x += FRAME_OUTER_TO_INNER_DIFF_X (f); You also wrote: I believe it is possible to solve this problem by preventing string relocation the same way as it is done for menu items where keyboard equivalents are displayed in the same menu item. Such menu items are constructed by the following code in xmenu_show (and GC doesn't corrupt these menu items): What it is doing is copying the strings to the stack. Indeed, that technique should work. Note that the code in the C_ALLOCA case probably has the same kind of bug that we are discussing, because it creates a Lisp string that could be moved: Lisp_Object spacer; spacer = Fmake_string (make_number (gap), make_number (' ')); item_name = concat2 (item_name, spacer); item_name = concat2 (item_name, descrip); item_data = SDATA (item_name); It probably doesn't matter, because probably nobody uses the C_ALLOCA case any more. I would expect that all those configurations have been obsolete for years. Anyway, my patch should fix that too.