From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: Re: kill-compilation failing when there are several compilation buffers Date: Thu, 02 Aug 2007 11:36:10 -0400 Message-ID: References: <87r6mndorr.fsf@jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1186068983 9178 80.91.229.12 (2 Aug 2007 15:36:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 2 Aug 2007 15:36:23 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 02 17:36:16 2007 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IGcim-00082F-9P for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 Aug 2007 17:36:16 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IGcil-0001Yq-Ma for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 Aug 2007 11:36:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IGcij-0001T1-B2 for bug-gnu-emacs@gnu.org; Thu, 02 Aug 2007 11:36:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IGcii-0001PT-55 for bug-gnu-emacs@gnu.org; Thu, 02 Aug 2007 11:36:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IGcih-0001Oj-Ul for bug-gnu-emacs@gnu.org; Thu, 02 Aug 2007 11:36:11 -0400 Original-Received: from tomts20.bellnexxia.net ([209.226.175.74] helo=tomts20-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IGcih-0006hK-IM for bug-gnu-emacs@gnu.org; Thu, 02 Aug 2007 11:36:11 -0400 Original-Received: from pastel.home ([74.12.205.233]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070802153610.NYSA8273.tomts20-srv.bellnexxia.net@pastel.home> for ; Thu, 2 Aug 2007 11:36:10 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 52B3580CD; Thu, 2 Aug 2007 11:36:09 -0400 (EDT) In-Reply-To: <87r6mndorr.fsf@jurta.org> (Juri Linkov's message of "Wed\, 01 Aug 2007 22\:43\:20 +0300") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-Detected-Kernel: Solaris 8 (1) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:16270 Archived-At: >>> ! (if (and (compilation-buffer-internal-p (current-buffer)) >>> ! (not avoid-current)) >>> ! (current-buffer) >>> ! (next-error-find-buffer avoid-current 'compilation-buffer-internal-p))) >> >> Curiously, next-error-find-buffer only checks current-buffer as its >> 3rd choice. This function either needs to be changed to try the current >> buffer as its first choice, or it needs a clear comment explaining why. >> >> It looks like this was changed by: >> >> revision 1.655 >> date: 2004-09-01 13:05:59 -0400; author: jurta; state: Exp; lines: +45 -45; >> * simple.el (next-error-find-buffer): Move the rule >> "if current buffer is a next-error capable buffer" after the >> rule "if next-error-last-buffer is set to a live buffer". >> Simplify to test all rules in one `or'. >> (next-error): Doc fix. >> >> where it is not explained. Juri, do you remember what was the motivation >> for this change? > This change was based on the conclusion of the very long discussion started > from http://lists.gnu.org/archive/html/emacs-devel/2004-05/msg00476.html [ Could the lists.gnu.org archives be fixed not to arbitrarily cut threads at month boundaries? ] > Any change in current rules may break test cases mentioned on that thread. Oh I see, so yes, Richard's patch to kill-compilation is about right: the complex rules of next-error-find-buffer are designed specifically for the use case of next-error, and the rules for kill-compilation should be slightly different. Stefan