kill-compilation failing when there are several compilation buffers

kill-compilation failing when there are several compilation buffers

[Edward Welbourne]

I have several compile buffers running in parallel.
One of them completed.
In examining its errors, and fixing them, I concluded that I need to restart the others.
So I went to one of them and typed C-c C-k.
I got a minibuffer message <quote>
kill-compilation: The compilation process is not running
</quote> The comilation didn't stop.
Same applied to the compilation in buffer *compilation*.

Reading the help C-h C-k got me on C-c C-k, I see it's (kill-compilation)
which takes no parameter to indicate which compilation to kill, if there
happen to be several.  I had been under the impression that C-c C-k killed
the current buffer's compilation previously, but the documentation doesn't
say anything relating to that.

It would seem that kill-compilation either:
 * needs an optional argument, indicating *which* buffer's compilation
   to kill, defaulting to the current buffer; or
 * is meant to kill the one in current buffer already; and has a bug !


In GNU Emacs 22.1.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2007-07-07 on raven, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.10300000
configured using `configure  '--build=i486-linux-gnu' '--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs22:/etc/emacs:/usr/local/share/emacs/22.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.1/leim' '--with-x=yes' '--with-x-toolkit=athena' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_GB.ISO-8859-15
  locale-coding-system: iso-8859-15
  default-enable-multibyte-characters: t

Major mode: Compilation

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
s SPC = SPC f f l u s h ( m _ f p ) ; C-j i f SPC ( 
r e s SPC = = SPC 0 ) C-j C-p m _ c o m m i t SPC & 
& SPC C-x o C-n C-n C-n C-n C-n C-a C-SPC C-n M-w C-x 
o C-a C-y C-n C-e <return> # e n d i f C-p C-e C-x 
o C-r f d a t a s y n c C-x C-x C-x o r e s SPC = SPC 
f d a t a s y n c ( f i l e n o ( m _ f p ) ) ; C-n 
C-j i f SPC ( r e s SPC = = SPC 0 ) C-n TAB C-n C-M-b 
C-M-f C-x C-s C-x o C-x b <return> C-p C-r e r r o 
r C-r C-r C-r C-r C-r C-r C-r C-r C-r C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p M-< C-M-s ^ C C-s C-f 
C-SPC C-e M-w C-x C-f C-y <return> C-x v u y e s <return> 
C-x 3 C-x k <return> C-x o C-M-s C-s C-f C-SPC C-e 
M-w C-x C-f C-y <return> C-x v u y e s <return> C-x 
3 C-x k <return> C-x o C-M-s C-s C-f C-SPC C-e M-w 
C-x C-f C-y <return> C-x v u y e s <return> C-x 3 C-x 
k <return> C-x o C-M-s C-s M-> C-x o C-x k <return> 
C-x b * p e <tab> s e <tab> <return> C-c C-k C-c C-k 
<help-echo> C-x o C-x b * c o m <tab> <return> M-> 
C-c C-k C-h k C-c C-k C-x o C-x k <return> M-x r e 
p o r <tab> <return>

Recent messages:
Reverting /disk/home/eddy/work/desk/peregrine/modules/libssl/sslstat1.cpp...
Checking out /disk/home/eddy/work/desk/peregrine/modules/libssl/sslstat1.cpp...done
Reverting /disk/home/eddy/work/desk/peregrine/modules/libssl/sslstat1.cpp...done
Mark saved where search started
Mark set
kill-compilation: The compilation process is not running [2 times]
Mark set
kill-compilation: The compilation process is not running
Type C-x 4 C-o RET to restore the other window.  
Loading emacsbug...done

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

[Richard Stallman]

    Reading the help C-h C-k got me on C-c C-k, I see it's (kill-compilation)
    which takes no parameter to indicate which compilation to kill, if there
    happen to be several.  I had been under the impression that C-c C-k killed
    the current buffer's compilation previously, but the documentation doesn't
    say anything relating to that.

C-c C-k ought to kill the current buffer's compilation if you are in a
compilation buffer.  If that doesn't reliably work, but is a bug.

Does this patch fix it?


Index: compile.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/compile.el,v
retrieving revision 1.421.2.5
diff -c -c -r1.421.2.5 compile.el
*** compile.el	25 Jul 2007 04:29:36 -0000	1.421.2.5
--- compile.el	1 Aug 2007 05:32:34 -0000
***************
*** 1604,1615 ****
      (setq compilation-current-error (point))
      (next-error-internal)))
  
- ;; Return a compilation buffer.
- ;; If the current buffer is a compilation buffer, return it.
- ;; Otherwise, look for a compilation buffer and signal an error
- ;; if there are none.
  (defun compilation-find-buffer (&optional avoid-current)
!   (next-error-find-buffer avoid-current 'compilation-buffer-internal-p))
  
  ;;;###autoload
  (defun compilation-next-error-function (n &optional reset)
--- 1609,1624 ----
      (setq compilation-current-error (point))
      (next-error-internal)))
  
  (defun compilation-find-buffer (&optional avoid-current)
!   "Return a compilation buffer.
! If AVOID-CURRENT is nil, and
! the current buffer is a compilation buffer, return it.
! If AVOID-CURRENT is non-nil, return the current buffer
! only as a last resort."
!   (if (and (compilation-buffer-internal-p (current-buffer))
! 	   (not avoid-current))
!       (current-buffer)
!     (next-error-find-buffer avoid-current 'compilation-buffer-internal-p)))
  
  ;;;###autoload
  (defun compilation-next-error-function (n &optional reset)

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

[Edward Welbourne]

> C-c C-k ought to kill the current buffer's compilation if you are in a
> compilation buffer.  If that doesn't reliably work, but is a bug.

OK, I'll watch out for if it repeats itself.

> Does this patch fix it?

Given how sporadic the bug is (I've seen it once in at least a
fortnight), I'll leave my system unchanged until I reproduce, then
over-ride compilation-find-buffer (by C-x C-e on the modified defun)
and see if it fixes the problem.  If I simply apply the patch, and
never see the bug again, I won't know whether some peculiarity that
provoked it the first time has never repeated, or whether it's fixed.

Unfortunately, the session in which the bug showed up is now lost -
I've had a sporadic problem with my X server zorching my session when
I go to a virtual console (C-M-F1, etc.) and come back (C-M-F7); it
bit again last night :-(

	Eddy.

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

[Edward Welbourne]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]

Hi again,

> C-c C-k ought to kill the current buffer's compilation if you are in a
> compilation buffer.  If that doesn't reliably work, but is a bug.

OK, now successfully reproduced: I started two compiles in separate
buffers, inadvertently using the same command in both (forgot to
history-back one of them !) and the command I'd used was the right
command for the buffer I started second, so I went to the one I'd
started first, which was in fact *compilation*, and C-c C-k'd in it;
but the later-started compilation got killed instead.

So this *is* a bug.

> Does this patch fix it?

No.  I put your replacement defun into a temp-buffer, removed its !
markers, C-c C-e'd it and set about re-testing in my handy pair of
compile buffers.  C-c C-k is now broken: I get <quote>

and: Wrong number of arguments: #[nil "ÀÁ!‡" [local-variable-p compilation-locs] 2 ("/usr/share/emacs/22.1/lisp/progmodes/compile.elc" . 48467)], 1

</quote> in *Messages* - which is puzzling, given that <quote src="*temp*">

  (defun compilation-find-buffer (&optional avoid-current)
   "Return a compilation buffer.
 If AVOID-CURRENT is nil, and
 the current buffer is a compilation buffer, return it.
 If AVOID-CURRENT is non-nil, return the current buffer
 only as a last resort."
   (if (and (compilation-buffer-internal-p (current-buffer))
 	   (not avoid-current))
       (current-buffer)
     (next-error-find-buffer avoid-current 'compilation-buffer-internal-p)))

</quote> the changed code quite plainly supplies (and CONDITIONS ...)
with two arguments, compatible with what C-h f says about it.  Then
again, I don't understand anything the error message says after the
second :

gah - rmail wants to know what coding system to use, so I guess it's
about to mangle that *Message* line.  It currently says:

and: Wrong number of arguments: #[nil "\300\301!\207" [local-variable-p compilation-locs] 2 ("/usr/share/emacs/22.1/lisp/progmodes/compile.elc" . 48467)], 1

except that the three escapes in "\300\301!\207" are actually single
characters, not the escape sequence as which they display (in blue).

	Eddy.

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

[Edward Welbourne]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2128 bytes --]

ah !
I tried evaluating sub-expressions, albeit not in a compile-buffer.
When I evaluate

(compilation-buffer-internal-p (current-buffer))

I get thrown to the debugger: <quote src="*Backtrace*">

Debugger entered--Lisp error: (wrong-number-of-arguments #[nil "ŽÀŽÁ!‡" [local-variable-p compilation-locs] 2 ("/usr/share/emacs/22.1/lisp/progmodes/compile.elc" . 48467)] 1)
  compilation-buffer-internal-p(#<buffer *temp*>)
  eval((compilation-buffer-internal-p (current-buffer)))
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp)

</quote> so the problem's there.  C-h f says <quote>

compilation-buffer-internal-p is a compiled Lisp function in `compile.el'.
(compilation-buffer-internal-p)

Test if inside a compilation buffer.

</quote> and /usr/share/emacs/22.1/lisp/progmodes/compile.el.gz
(helpfully uncompressed on the fly by emacs) says: <quote>

;;; test if a buffer is a compilation buffer, assuming we're in the buffer
(defsubst compilation-buffer-internal-p ()
  "Test if inside a compilation buffer."
  (local-variable-p 'compilation-locs))

;;; test if a buffer is a compilation buffer, using compilation-buffer-internal-p
(defsubst compilation-buffer-p (buffer)
  "Test if BUFFER is a compilation buffer."
  (with-current-buffer buffer
    (compilation-buffer-internal-p)))

</quote> so it looks like a typo in your patch - it should either call
compilation-buffer-p or omit the (current-buffer) parameter to
compilation-buffer-internal-p.  (I should also note that the error
message produced, claiming and got the wrong number of arguments, was
was not so helpful !)

Changing the defun to <quote>

(defun compilation-find-buffer (&optional avoid-current)
  "Return a compilation buffer.
If AVOID-CURRENT is nil, and
the current buffer is a compilation buffer, return it.
If AVOID-CURRENT is non-nil, return the current buffer
only as a last resort."
  (if (and (compilation-buffer-internal-p)
	   (not avoid-current))
      (current-buffer)
    (next-error-find-buffer avoid-current 'compilation-buffer-internal-p)))

</quote> and doing C-c C-e to that fixes the bug :-)

	Eddy.

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

[Richard Stallman]

Thanks.  I will install your correction.

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

[Juri Linkov]

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

Any change in current rules may break test cases mentioned on that thread.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Stefan Monnier]

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