Re: kill-compilation failing when there are several compilation buffers

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> !   (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