From unknown Wed Jun 18 23:04:30 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#4914 <4914@debbugs.gnu.org> To: bug#4914 <4914@debbugs.gnu.org> Subject: Status: completions - remove window after use? Reply-To: bug#4914 <4914@debbugs.gnu.org> Date: Thu, 19 Jun 2025 06:04:30 +0000 retitle 4914 completions - remove window after use? reassign 4914 emacs submitter 4914 David Reitter severity 4914 normal thanks From david.reitter@gmail.com Thu Nov 12 05:32:06 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 12 Nov 2009 13:32:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nACDW48V007663 for ; Thu, 12 Nov 2009 05:32:06 -0800 Received: from mail.gnu.org ([199.232.76.166]:57650 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1N8ZmO-0007iG-2r for emacs-pretest-bug@gnu.org; Thu, 12 Nov 2009 08:32:04 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1N8ZmM-00007A-Pv for emacs-pretest-bug@gnu.org; Thu, 12 Nov 2009 08:32:03 -0500 Received: from mail-yw0-f194.google.com ([209.85.211.194]:58442) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8ZmK-00006R-Ae for emacs-pretest-bug@gnu.org; Thu, 12 Nov 2009 08:32:01 -0500 Received: by ywh32 with SMTP id 32so2110900ywh.14 for ; Thu, 12 Nov 2009 05:31:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=6obOVKMpboMlJBjVY47Q6a6tg+7CNwQ4PEuW8+0owUw=; b=K3i7dBllu0dS5Kfwgc7N/ZWJaxzIG3BIAhNP8Ws39eDkDGVHRQLHH899E0QS5n5L0+ FRaIrt0hJTotG7kH1f6SI2KEshKfNaD+jUujVOQE/dAJm2VLjlcxFeAO81HOPRhXdgJZ p1e5mwOqF3xOHEmjvzrD0nvwLLeY0wPHbiA3A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=a6iEhN5OXsODXYlM8bgVOOOOl8yvFjKfiWWoCRS1iSZD5zqxcYqogWwsUu4zgpie21 n71o4auEVkqwpKGdPWO5tShmmmjwBUm8uxl0m+w5CgPCWddQNrcKkfHlbJdMVOhwLhqE dv8RLSR64ol+odE47m1mMKCdIyk/ep4j9iabs= Received: by 10.100.193.12 with SMTP id q12mr2487514anf.43.1258032715724; Thu, 12 Nov 2009 05:31:55 -0800 (PST) Received: from scarlett.local (pool-96-235-8-122.pitbpa.east.verizon.net [96.235.8.122]) by mx.google.com with ESMTPS id 6sm1044499ywc.9.2009.11.12.05.31.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 12 Nov 2009 05:31:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) Subject: Re: completions - remove window after use? From: David Reitter In-Reply-To: <4AFBC50D.1060007@gmx.at> Date: Thu, 12 Nov 2009 08:31:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6B8057CC-08E3-4A6F-BDCC-0A8CBD738365@gmail.com> References: <61C01A08-8FB6-4908-B9F1-B9F1CE3E3D92@gmail.com> <4AFBC50D.1060007@gmx.at> To: emacs-pretest-bug@gnu.org X-Mailer: Apple Mail (2.1077) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) >=20 > > When showing a *completions* buffer in a new window opened for > > it (TAB in find-file minibuffer for instance), I wonder why the > > window doesn't get deleted when completion has finished. For > > instance, when an existing file is found, the *Completions* > > buffer is buried, but I see a split frame with the original > > buffer in the top window and _some other_ buffer in the lower > > window. Shouldn't the window for the completions buffer be > > removed whenever it has been popped up just for the buffer? >=20 On Nov 12, 2009, at 3:19 AM, martin rudalics wrote: > This should not happen and doesn't happen with my older builds. Could > you please (1) make sure that the behavior also happens with Emacs -Q, > (2) try to find out when it appeared for the first time, and (3) make = a > corresponding bug report. I reproduce this with a current build, with emacs -nw -Q. When reverting to revision e78283bb (Tue Aug 18, just before = minibuffer-hide-completions was introduced), the problem goes away and = the *Completions* buffer continuous to be shown in the extra window. I think it's now burying the buffer, but doesn't delete the window. Again, the desired behavior would be to remove windows (or frames) that = were created to display the *Completions* buffer rather than to leave = them visible.= From rudalics@gmx.at Thu Nov 12 09:40:34 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 12 Nov 2009 17:40:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.2 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nACHeWjV030064 for ; Thu, 12 Nov 2009 09:40:34 -0800 Received: from mail.gnu.org ([199.232.76.166]:44099 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1N8deq-0005dM-6o for emacs-pretest-bug@gnu.org; Thu, 12 Nov 2009 12:40:32 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1N8deo-0002MR-BS for emacs-pretest-bug@gnu.org; Thu, 12 Nov 2009 12:40:31 -0500 Received: from mail.gmx.net ([213.165.64.20]:60768) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1N8den-0002Ly-QX for emacs-pretest-bug@gnu.org; Thu, 12 Nov 2009 12:40:30 -0500 Received: (qmail invoked by alias); 12 Nov 2009 17:40:26 -0000 Received: from 62-47-62-238.adsl.highway.telekom.at (EHLO [62.47.62.238]) [62.47.62.238] by mail.gmx.net (mp008) with SMTP; 12 Nov 2009 18:40:26 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18KMBEEcckKXJnkpoJM+AJeC2FI821f9nCGg2oFqs S9me3vHXVJJBNM Message-ID: <4AFC4889.6090707@gmx.at> Date: Thu, 12 Nov 2009 18:40:25 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Reitter , 4914@debbugs.gnu.org CC: emacs-pretest-bug@gnu.org Subject: Re: bug#4914: completions - remove window after use? References: <61C01A08-8FB6-4908-B9F1-B9F1CE3E3D92@gmail.com> <4AFBC50D.1060007@gmx.at> <6B8057CC-08E3-4A6F-BDCC-0A8CBD738365@gmail.com> In-Reply-To: <6B8057CC-08E3-4A6F-BDCC-0A8CBD738365@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) > When reverting to revision e78283bb (Tue Aug 18, just before > minibuffer-hide-completions was introduced), the problem goes away and > the *Completions* buffer continuous to be shown in the extra window. > I think it's now burying the buffer, but doesn't delete the window. I wasn't aware of that. Is the new behavior anywhere documented? > Again, the desired behavior would be to remove windows (or frames) > that were created to display the *Completions* buffer rather than to > leave them visible. Deleting the window isn't necessarily the right thing either - think of the case where displaying the *completions* buffer reuses an existing window instead of popping up a new one. I'm currently experimenting with a generic solution for this problem. martin From david.reitter@gmail.com Thu Nov 12 09:57:02 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 12 Nov 2009 17:57:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nACHv09r031230 for ; Thu, 12 Nov 2009 09:57:02 -0800 Received: from mx10.gnu.org ([199.232.76.166]:44708) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1N8dum-0006EJ-BT for emacs-pretest-bug@gnu.org; Thu, 12 Nov 2009 12:57:00 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1N8dui-00050S-K0 for emacs-pretest-bug@gnu.org; Thu, 12 Nov 2009 12:57:00 -0500 Received: from qw-out-1920.google.com ([74.125.92.148]:19152) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8dui-00050O-Bu for emacs-pretest-bug@gnu.org; Thu, 12 Nov 2009 12:56:56 -0500 Received: by qw-out-1920.google.com with SMTP id 5so493887qwc.24 for ; Thu, 12 Nov 2009 09:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=/vueS9PzeZ9LGrxy6uNAeWfXgimFfv3qdw7oji2VFpw=; b=YEZv3y3zLj7kP8WIqoNU44B3MALTm8EDi1F0HeJ535JzagNJoQrnqBMUY6wLfccFKr GPDdCiD4T2LbI8XNWwbvQsX2dbSryVko1ji/iB3VORsfxJp8BqSvrTBXVTBcTMR3h3Rj C86n55oaw5rXdSfn5poHwC5opM4fwkzySKHDg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=nJxcA05RQ7sotBtNFrTXchC/PkH9E7ZlsYqIOQ5fYqZfs126niZCJCBEs4Nm81DD5o sHA924khTadrohHevGMObTHBHRjwO/imBzGAM2W6Y2RfnFNlWv3c+Ql0V2SdFKa8WX0E 0/vsIUCYRMCOeVpOQ5Hn3T+vI2os4EAGXT48U= Received: by 10.224.42.83 with SMTP id r19mr1829592qae.35.1258048613133; Thu, 12 Nov 2009 09:56:53 -0800 (PST) Received: from scarlett.psy.cmu.edu (SCARLETT.PSY.CMU.EDU [128.2.249.106]) by mx.google.com with ESMTPS id 20sm729160qyk.9.2009.11.12.09.56.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 12 Nov 2009 09:56:51 -0800 (PST) Subject: Re: bug#4914: completions - remove window after use? Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: David Reitter In-Reply-To: <4AFC4889.6090707@gmx.at> Date: Thu, 12 Nov 2009 12:56:47 -0500 Cc: 4914@debbugs.gnu.org, emacs-pretest-bug@gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <22B10138-7AD6-4138-BD23-DA62D9B79BCB@gmail.com> References: <61C01A08-8FB6-4908-B9F1-B9F1CE3E3D92@gmail.com> <4AFBC50D.1060007@gmx.at> <6B8057CC-08E3-4A6F-BDCC-0A8CBD738365@gmail.com> <4AFC4889.6090707@gmx.at> To: martin rudalics X-Mailer: Apple Mail (2.1077) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) On Nov 12, 2009, at 12:40 PM, martin rudalics wrote: > > Again, the desired behavior would be to remove windows (or frames) > > that were created to display the *Completions* buffer rather than to > > leave them visible. >=20 > Deleting the window isn't necessarily the right thing either - think = of > the case where displaying the *completions* buffer reuses an existing > window instead of popping up a new one. I'm currently experimenting > with a generic solution for this problem. That would be good. Quite generally, those windows/frames that are = created (e.g. via pop-to-buffer) for a specific window should be removed = after we're done with the interaction (see also quit-window). I've had = a kludge for this in Aquamacs for a long time (via an advice to = bury-buffer), but it's quite difficult to do consistently when Emacs and = 3rd-part packages aren't aware that this is happening. Are dedicated windows the way to go?= From rudalics@gmx.at Thu Nov 12 11:27:02 2009 Received: (at 4914) by emacsbugs.donarmstrong.com; 12 Nov 2009 19:27:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.2 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id nACJQxpL009165 for <4914@emacsbugs.donarmstrong.com>; Thu, 12 Nov 2009 11:27:01 -0800 Received: (qmail invoked by alias); 12 Nov 2009 19:26:52 -0000 Received: from 62-47-62-238.adsl.highway.telekom.at (EHLO [62.47.62.238]) [62.47.62.238] by mail.gmx.net (mp012) with SMTP; 12 Nov 2009 20:26:52 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+Y8BFRiySYnELdWOydhBUjTzJD9MOWwiiThWz2Vx kVTPFaxj8jUC4l Message-ID: <4AFC6176.3010306@gmx.at> Date: Thu, 12 Nov 2009 20:26:46 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Reitter CC: 4914@debbugs.gnu.org Subject: Re: bug#4914: completions - remove window after use? References: <61C01A08-8FB6-4908-B9F1-B9F1CE3E3D92@gmail.com> <4AFBC50D.1060007@gmx.at> <6B8057CC-08E3-4A6F-BDCC-0A8CBD738365@gmail.com> <4AFC4889.6090707@gmx.at> <22B10138-7AD6-4138-BD23-DA62D9B79BCB@gmail.com> In-Reply-To: <22B10138-7AD6-4138-BD23-DA62D9B79BCB@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.73 > That would be good. Quite generally, those windows/frames that are > created (e.g. via pop-to-buffer) for a specific window should be > removed after we're done with the interaction (see also quit-window). > I've had a kludge for this in Aquamacs for a long time (via an advice > to bury-buffer), but it's quite difficult to do consistently when > Emacs and 3rd-part packages aren't aware that this is happening. It's practically impossible to find a solution that satisfies all needs in this area. Basically, `display-buffer' would set a special slot for any window it pops up and `quit-window' would try to delete a window if it has that slot set and still shows the argument of `display-buffer'. The more difficult part is what to do when `display-buffer' has reused an existing window. In that case quitting that window should display the previous buffer with the old start position and the old point. All these values would have to be recorded in the window structure and in saved window configurations. Now once we have all these values we could have `bury-buffer' use them instead of doing a `switch-to-buffer' but that's too tricky for the moment. > Are dedicated windows the way to go? The completions window could be dedicated so `quit-window' would automatically delete it. Windows that may live longer should generally not be dedicated. martin From monnier@IRO.UMontreal.CA Thu Nov 12 12:22:38 2009 Received: (at 4914) by emacsbugs.donarmstrong.com; 12 Nov 2009 20:22:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from pruche.dit.umontreal.ca (pruche.dit.umontreal.ca [132.204.246.22]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nACKMRHb015687 for <4914@emacsbugs.donarmstrong.com>; Thu, 12 Nov 2009 12:22:29 -0800 Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id nACKMLPa031874; Thu, 12 Nov 2009 15:22:22 -0500 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id F2F293A461; Thu, 12 Nov 2009 15:22:18 -0500 (EST) From: Stefan Monnier To: David Reitter Cc: 4914@debbugs.gnu.org, martin rudalics Subject: Re: bug#4914: completions - remove window after use? Message-ID: References: <61C01A08-8FB6-4908-B9F1-B9F1CE3E3D92@gmail.com> <4AFBC50D.1060007@gmx.at> <6B8057CC-08E3-4A6F-BDCC-0A8CBD738365@gmail.com> <4AFC4889.6090707@gmx.at> <22B10138-7AD6-4138-BD23-DA62D9B79BCB@gmail.com> Date: Thu, 12 Nov 2009 15:22:18 -0500 In-Reply-To: <22B10138-7AD6-4138-BD23-DA62D9B79BCB@gmail.com> (David Reitter's message of "Thu, 12 Nov 2009 12:56:47 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3405=0 > Are dedicated windows the way to go? Yes, soft-dedicated windows might be the way to go. But the change you refer to (in revision e78283bb, whatever that is) was not intentional, so we could/should start by fixing that change. Stefan From monnier@IRO.UMontreal.CA Tue Nov 17 15:00:37 2009 Received: (at 4914) by emacsbugs.donarmstrong.com; 17 Nov 2009 23:00:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.8 required=4.0 tests=AWL,FOURLA,FVGT_m_MULTI_ODD, HAS_BUG_NUMBER,MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from chene.dit.umontreal.ca (chene.dit.umontreal.ca [132.204.246.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nAHN0YdY031910 for <4914@emacsbugs.donarmstrong.com>; Tue, 17 Nov 2009 15:00:36 -0800 Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id nAHN0Wei024554; Tue, 17 Nov 2009 18:00:32 -0500 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id E4A393A0FA; Tue, 17 Nov 2009 18:00:31 -0500 (EST) From: Stefan Monnier To: martin rudalics Cc: David Reitter , 4914@debbugs.gnu.org Subject: Re: bug#4914: completions - remove window after use? Message-ID: References: <61C01A08-8FB6-4908-B9F1-B9F1CE3E3D92@gmail.com> <4AFBC50D.1060007@gmx.at> <6B8057CC-08E3-4A6F-BDCC-0A8CBD738365@gmail.com> <4AFC4889.6090707@gmx.at> <22B10138-7AD6-4138-BD23-DA62D9B79BCB@gmail.com> <4AFC6176.3010306@gmx.at> Date: Tue, 17 Nov 2009 18:00:31 -0500 In-Reply-To: <4AFC6176.3010306@gmx.at> (martin rudalics's message of "Thu, 12 Nov 2009 20:26:46 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3408=0 >> That would be good. Quite generally, those windows/frames that are >> created (e.g. via pop-to-buffer) for a specific window should be >> removed after we're done with the interaction (see also quit-window). >> I've had a kludge for this in Aquamacs for a long time (via an advice >> to bury-buffer), but it's quite difficult to do consistently when >> Emacs and 3rd-part packages aren't aware that this is happening. > It's practically impossible to find a solution that satisfies all needs > in this area. Basically, `display-buffer' would set a special slot for > any window it pops up and `quit-window' would try to delete a window if > it has that slot set and still shows the argument of `display-buffer'. How 'bout the patch below? Stefan "whose .emacs would have (setq display-buffer-mark-dedicated 'soft)" Index: lisp/minibuffer.el =================================================================== RCS file: /sources/emacs/emacs/lisp/minibuffer.el,v retrieving revision 1.96 diff -u -r1.96 minibuffer.el --- lisp/minibuffer.el 12 Nov 2009 23:10:06 -0000 1.96 +++ lisp/minibuffer.el 17 Nov 2009 22:56:12 -0000 @@ -965,9 +965,14 @@ (if (and completions (or (consp (cdr completions)) (not (equal (car completions) string)))) - (with-output-to-temp-buffer "*Completions*" (let* ((last (last completions)) - (base-size (cdr last))) + (base-size (cdr last)) + ;; If the *Completions* buffer is shown in a new + ;; window, mark it as softly-dedicated, so bury-buffer in + ;; minibuffer-hide-completions will know whether to + ;; delete the window or not. + (display-buffer-mark-dedicated 'soft)) + (with-output-to-temp-buffer "*Completions*" ;; Remove the base-size tail because `sort' requires a properly ;; nil-terminated list. (when last (setcdr last nil)) Index: lisp/window.el =================================================================== RCS file: /sources/emacs/emacs/lisp/window.el,v retrieving revision 1.185 diff -u -r1.185 window.el --- lisp/window.el 13 Nov 2009 22:19:56 -0000 1.185 +++ lisp/window.el 17 Nov 2009 22:56:12 -0000 @@ -1042,6 +1042,11 @@ (set-window-buffer window buffer) (window--display-buffer-1 window))) +(defvar display-buffer-mark-dedicated nil + "If non-nil, `display-buffer' marks the windows it creates as dedicated. +The actual non-nil value of this variable will be copied to the +`window-dedicated-p' flag.") + (defun display-buffer (buffer-or-name &optional not-this-window frame) "Make buffer BUFFER-OR-NAME appear in some window but don't select it. BUFFER-OR-NAME must be a buffer or the name of an existing @@ -1133,8 +1133,10 @@ buffer (if (listp pars) pars)))))) ((or use-pop-up-frames (not frame-to-use)) ;; We want or need a new frame. - (window--display-buffer-2 - buffer (frame-selected-window (funcall pop-up-frame-function)))) + (let ((win (frame-selected-window (funcall pop-up-frame-function)))) + (when display-buffer-mark-dedicated + (set-window-dedicated-p win display-buffer-mark-dedicated)) + (window--display-buffer-2 buffer win))) ((and pop-up-windows ;; Make a new window. (or (not (frame-parameter frame-to-use 'unsplittable)) @@ -1149,8 +1149,10 @@ (or (window--try-to-split-window (get-largest-window frame-to-use t)) (window--try-to-split-window - (get-lru-window frame-to-use t)))) - (window--display-buffer-2 buffer window-to-use))) + (get-lru-window frame-to-use t))))) + (when display-buffer-mark-dedicated + (set-window-dedicated-p window-to-use display-buffer-mark-dedicated)) + (window--display-buffer-2 buffer window-to-use)) ((let ((window-to-undedicate ;; When NOT-THIS-WINDOW is non-nil, temporarily dedicate ;; the selected window to its buffer, to avoid that some of From rudalics@gmx.at Wed Nov 18 00:11:50 2009 Received: (at 4914) by emacsbugs.donarmstrong.com; 18 Nov 2009 08:11:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-4.1 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id nAI8BmvR020915 for <4914@emacsbugs.donarmstrong.com>; Wed, 18 Nov 2009 00:11:49 -0800 Received: (qmail invoked by alias); 18 Nov 2009 08:11:42 -0000 Received: from 62-47-61-175.adsl.highway.telekom.at (EHLO [62.47.61.175]) [62.47.61.175] by mail.gmx.net (mp003) with SMTP; 18 Nov 2009 09:11:42 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19g3fRPtXdgfWHXx00/p0WFNeeDcWo0tcUijxjqyh sA5sXPhCVUBZX0 Message-ID: <4B03AC3C.9000300@gmx.at> Date: Wed, 18 Nov 2009 09:11:40 +0100 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Stefan Monnier CC: David Reitter , 4914@debbugs.gnu.org Subject: Re: bug#4914: completions - remove window after use? References: <61C01A08-8FB6-4908-B9F1-B9F1CE3E3D92@gmail.com> <4AFBC50D.1060007@gmx.at> <6B8057CC-08E3-4A6F-BDCC-0A8CBD738365@gmail.com> <4AFC4889.6090707@gmx.at> <22B10138-7AD6-4138-BD23-DA62D9B79BCB@gmail.com> <4AFC6176.3010306@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68 >> It's practically impossible to find a solution that satisfies all needs >> in this area. Basically, `display-buffer' would set a special slot for >> any window it pops up and `quit-window' would try to delete a window if >> it has that slot set and still shows the argument of `display-buffer'. > > How 'bout the patch below? > > > Stefan "whose .emacs would have > (setq display-buffer-mark-dedicated 'soft)" This reveals a general problem with all `display-buffer' related (and maybe all) options. We really should settle on a policy that strictly separates user provided settings from application provided ones. In particular > + ;; If the *Completions* buffer is shown in a new > + ;; window, mark it as softly-dedicated, so bury-buffer in > + ;; minibuffer-hide-completions will know whether to > + ;; delete the window or not. > + (display-buffer-mark-dedicated 'soft)) > + (with-output-to-temp-buffer "*Completions*" > ;; Remove the base-size tail because `sort' requires a properly > ;; nil-terminated list. > (when last (setcdr last nil)) overrides the intentions of a user who has an explicit (setq display-buffer-mark-dedicated nil) in her .emacs. Also I suppose that with your .emacs `display-buffer' won't be able to reuse a window it popped up earlier for displaying another buffer. In the case at hand this would prevent the Completions window's contents getting overwritten by those of some other buffer which is good. But in general this might be a bad idea leading to "more important" windows getting reused and/or new windows and frames popped up all the time. Also note that the greater problem is still how to "correctly" quit a window that has been reused (instead of popped up) by `display-buffer'. martin From david.reitter@gmail.com Mon Nov 23 05:58:46 2009 Received: (at 4914) by emacsbugs.donarmstrong.com; 23 Nov 2009 13:58:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.4 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-qy0-f197.google.com (mail-qy0-f197.google.com [209.85.221.197]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nANDwjSp012566 for <4914@emacsbugs.donarmstrong.com>; Mon, 23 Nov 2009 05:58:46 -0800 Received: by qyk35 with SMTP id 35so2554723qyk.19 for <4914@emacsbugs.donarmstrong.com>; Mon, 23 Nov 2009 05:58:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=BrLDTRT84k05bX69gZy4u3EuuhIgvTVkYdnL8/pV3JM=; b=lIV9abP/wvwrcou+zqJ32xQxRrcmYIBmQjHNSuobRAyeIdp9tY5DvnbmipcPDCyNcm Ny711cP4ij03Riod/PqEf97zJku82D+EfxrLV+L71c11W5HeHffhOMztmvdBAyW4Xw2x nViLWTGWnGXaCQd9CJpr6ftzDk72g2YdKWkdw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=sKhbbLbYLJL72cvt+HXgi9uQXYrrOOWIAXvxc3uBo6Lk3p67d0R6VMVBhFvLBdEqyh IhXtTnS4xLfR48dAItMDO19loco9r2Lg+9Vt3Xq/EkGEcY+WZU5t41RSZR78ZWRIcBun LXy/Co9Gj9fvypEu3qjIvLf7KtoclHruBj3uA= Received: by 10.224.82.11 with SMTP id z11mr2457409qak.87.1258984719673; Mon, 23 Nov 2009 05:58:39 -0800 (PST) Received: from scarlett.local (pool-96-236-188-111.pitbpa.east.verizon.net [96.236.188.111]) by mx.google.com with ESMTPS id 7sm12328982qwf.24.2009.11.23.05.58.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Nov 2009 05:58:37 -0800 (PST) Subject: Re: bug#4914: completions - remove window after use? Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: David Reitter In-Reply-To: Date: Mon, 23 Nov 2009 08:58:34 -0500 Cc: martin rudalics , 4914@debbugs.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <87D25073-CE7E-4C9E-B094-0C3C6C2071AE@gmail.com> References: <61C01A08-8FB6-4908-B9F1-B9F1CE3E3D92@gmail.com> <4AFBC50D.1060007@gmx.at> <6B8057CC-08E3-4A6F-BDCC-0A8CBD738365@gmail.com> <4AFC4889.6090707@gmx.at> <22B10138-7AD6-4138-BD23-DA62D9B79BCB@gmail.com> <4AFC6176.3010306@gmx.at> To: Stefan Monnier X-Mailer: Apple Mail (2.1077) On Nov 17, 2009, at 6:00 PM, Stefan Monnier wrote: > How 'bout the patch below? > (setq display-buffer-mark-dedicated 'soft)" Didn't work that well for me - the window doesn't disappear. Perhaps the = other bug (switching away from *Completions*) would need to be fixed = first. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 17 18:41:17 2010 Received: (at 4914) by debbugs.gnu.org; 17 Jan 2010 23:41:18 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NWek9-00079W-8O for submit@debbugs.gnu.org; Sun, 17 Jan 2010 18:41:17 -0500 Received: from pantheon-po39.its.yale.edu ([130.132.50.100]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NWek7-00079N-M1 for 4914@debbugs.gnu.org; Sun, 17 Jan 2010 18:41:16 -0500 Received: from furry (dhcp128036014123.central.yale.edu [128.36.14.123]) (authenticated bits=0) by pantheon-po39.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o0HNfBtZ020420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 17 Jan 2010 18:41:11 -0500 Received: by furry (Postfix, from userid 1000) id D084BC05D; Sun, 17 Jan 2010 16:41:11 -0700 (MST) From: Chong Yidong To: David Reitter Subject: Re: completions - remove window after use? Date: Sun, 17 Jan 2010 18:41:11 -0500 Message-ID: <87k4vg9u5k.fsf@stupidchicken.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 4914 Cc: 4914@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) > > When showing a *completions* buffer in a new window opened for > > it (TAB in find-file minibuffer for instance), I wonder why the > > window doesn't get deleted when completion has finished. For > > instance, when an existing file is found, the *Completions* > > buffer is buried, but I see a split frame with the original > > buffer in the top window and _some other_ buffer in the lower > > window. Shouldn't the window for the completions buffer be > > removed whenever it has been popped up just for the buffer? > > I reproduce this with a current build, with emacs -nw -Q. Do you still see this bug? I think it's been fixed for a while now (at least I don't experience it). From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 18 10:08:12 2010 Received: (at 4914-done) by debbugs.gnu.org; 18 Jan 2010 15:08:12 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NWtD9-0008Hi-5O for submit@debbugs.gnu.org; Mon, 18 Jan 2010 10:08:11 -0500 Received: from mail-yx0-f193.google.com ([209.85.210.193]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NWtD8-0008Hd-9s for 4914-done@debbugs.gnu.org; Mon, 18 Jan 2010 10:08:10 -0500 Received: by yxe31 with SMTP id 31so498356yxe.21 for <4914-done@debbugs.gnu.org>; Mon, 18 Jan 2010 07:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-pgp-agent:x-mailer; bh=Xycimou7bygMXqDmUaW2lNMmb5OaIl3VSv9gCUfeUNc=; b=OvO/LHwSQUt56PCAuUhVFKt8AhoWSfL8+O/ruoa4HWNIAehphfYWQ6CcTt7+Awfnza E0Cl2nayIPy34lO90nJ3nUGrNamcM3oDwA2X7l3D3HqzvLrqRC0HsMLeGFCyKi+9ZVo5 XbqYkYv1e3/vEcMes74QekeAwI+ogmNFyxRGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-pgp-agent :x-mailer; b=FcJg5CxNLvbfCtSnL5K195QhKbcFqmUqSL35P7uj5quQijNO+xwJve7Nlb5l81Afge p2uE8IRC65p/HZ9yZ+nXSQ5V3cdCGUHkMimHLlrqL3ML6M+XODA1yeWV/zuLHDFtgADL EIvjTseLjf/mC4NuAQPOD77GnhGPnSAr7aVm8= Received: by 10.151.2.34 with SMTP id e34mr1447382ybi.195.1263827279371; Mon, 18 Jan 2010 07:07:59 -0800 (PST) Received: from ?192.168.1.42? (pool-96-236-181-152.pitbpa.east.verizon.net [96.236.181.152]) by mx.google.com with ESMTPS id 9sm656464yxf.5.2010.01.18.07.07.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 Jan 2010 07:07:56 -0800 (PST) Subject: Re: completions - remove window after use? Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-22--95251457" From: David Reitter In-Reply-To: <87k4vg9u5k.fsf@stupidchicken.com> Date: Mon, 18 Jan 2010 10:07:53 -0500 Content-Transfer-Encoding: 7bit Message-Id: <5C420BAC-187B-4B19-BF13-CC1A71745D59@gmail.com> References: <87k4vg9u5k.fsf@stupidchicken.com> To: Chong Yidong X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1077) X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 4914-done Cc: 4914-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-22--95251457 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 17, 2010, at 6:41 PM, Chong Yidong wrote: > Do you still see this bug? I think it's been fixed for a while now = (at > least I don't experience it). Yes, this particular case has been fixed, thank you.=20 I recall the general case being discussed but not addressed (closing = windows which have popped open just for a specific buffer), but I'll = file a separate report when I observe a striking example.= --Apple-Mail-22--95251457 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) iEYEARECAAYFAktUeUkACgkQYotoJUVQB4I43wCfe7RxQZRhMHxV2CYJyiSmO8kn HTEAn0lDeqWeMOFmLqFsj2eTHK/ppagg =yk4v -----END PGP SIGNATURE----- --Apple-Mail-22--95251457-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 18 12:58:33 2010 Received: (at 4914) by debbugs.gnu.org; 18 Jan 2010 17:58:33 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NWvs0-0003kM-O6 for submit@debbugs.gnu.org; Mon, 18 Jan 2010 12:58:32 -0500 Received: from qw-out-2122.google.com ([74.125.92.26]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NWvrz-0003k7-7A for 4914@debbugs.gnu.org; Mon, 18 Jan 2010 12:58:31 -0500 Received: by qw-out-2122.google.com with SMTP id 5so164629qwi.33 for <4914@debbugs.gnu.org>; Mon, 18 Jan 2010 09:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-pgp-agent:x-mailer; bh=7/m2icpSAm0e5mVLGLVZh/SMCVRhmXJwAuCJ+8CeQww=; b=LrvGJlMx1ix/DoszDIghUxmdtEcbPvZMuOmR8CvEOjf7AdFF7UUv2dLYsPX+/46CHi 9W9v0OeoZYnQpVlwVpvX1Gdw5s81Laxk4N2Nj6HtkgGFYtlj2Wj310OZInsTWl1Y32k4 eoLLFcuoffn3c63Ee5LSRmyi1/TZ0c5x/K/qI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-pgp-agent :x-mailer; b=X2fQYgVUTjVzd6WWGjapYQ60XefN3vMhd/Ht7F5niGizlgSa7XCv5rCGM7fAglw0J/ nA70un8IyorVmtVltv3959pCJW3UG58Lcs5Pq97XnIIIx1ygYzkQuHQHJk1+H4DKNfX/ TDnuGxziNKaZFDeXUQsg56E7E58cJ4AoFRniA= Received: by 10.224.85.76 with SMTP id n12mr3605593qal.46.1263837491608; Mon, 18 Jan 2010 09:58:11 -0800 (PST) Received: from cmu-365842.wv.cc.cmu.edu (CMU-365842.WV.CC.CMU.EDU [128.237.252.37]) by mx.google.com with ESMTPS id 22sm5295884qyk.14.2010.01.18.09.58.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 Jan 2010 09:58:09 -0800 (PST) Subject: Re: completions - remove window after use? Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-24--85041599" From: David Reitter In-Reply-To: <5C420BAC-187B-4B19-BF13-CC1A71745D59@gmail.com> Date: Mon, 18 Jan 2010 12:58:03 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <87k4vg9u5k.fsf@stupidchicken.com> <5C420BAC-187B-4B19-BF13-CC1A71745D59@gmail.com> To: Chong Yidong X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1077) X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 4914 Cc: 4914@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-24--85041599 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 18, 2010, at 10:07 AM, David Reitter wrote: > I recall the general case being discussed but not addressed (closing = windows which have popped open just for a specific buffer), but I'll = file a separate report when I observe a striking example. Actually, it seems to be working: C-h f foo RET C-x o C-x k RET pops up = and removes the window, iff (eq display-buffer-mark-dedicated 'soft). = I guess that was Stefan's patch. Very nice. I can get rid of my = kill-buffer kludges now. Thanks again. --Apple-Mail-24--85041599 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) iEYEARECAAYFAktUoS8ACgkQYotoJUVQB4KSpwCfbGIL3FIlOfX8/TIbU4brXijw LXgAnjmvzr0t9OMMoO8xHiY9ynnfG8Mb =4Ja3 -----END PGP SIGNATURE----- --Apple-Mail-24--85041599-- From unknown Wed Jun 18 23:04:30 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 16 Feb 2010 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A long time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator