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

next-error-find-buffer (was: 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

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

Actually, that thread did not conclude that the current set of rules is The
Right Way.  It ignored my suggestion (which was to keep the
`current-buffer' as the first rule, but to disable it if current-buffer was
the last source buffer visited by next-error).

Interestingly, I found out in the mean time that my suggestion has another
advantage: not only it ignores the current-buffer less often but it also
correctly ignores it in some cases where the current rules don't.

To remind people of the context, C-x ` has two problems:

1 - if you have two projects, do C-x ` in the first, then do C-x ` in the
    second, and then come back to the first and do C-x ` again, you'd want
    this C-x ` to use the compilation buffer of the first project, not of
    the second one.  So you'd want to sometimes ignore
    next-error-last-buffer.  This is the reason why "next-error capable
    buffer in the current frame" currently takes precedence over
    next-error-last-buffer.

2 - if you do C-x ` on a compilation buffer and that jumps to a patch file,
    and then do C-x ` from that patch file's buffer, it should look for the
    next error in the compilation buffer rather than the next hunk in the
    patch file.
    Currently this is done by giving precedence to next-error-last-buffer
    over current-buffer (i.e. basically this always ignores
    current-buffer.  In practice current-buffer is still often used because
    of the first rule "next-error capable buffer in current frame").

The way I use Emacs, I have one frame per buffer.  So the first rule
basically means that current-buffer is always selected, so for me problem
number 2 is not corrected.

My original suggestion to fix number 2 was to introduce a new variable
next-error-last-source-buffer which is set to the last source buffer visited
by next-error.  Then C-x ` would ignore current-buffer (and obey
next-error-last-buffer instead) if the current buffer is equal to
next-error-last-source-buffer: in the example problem, the C-x ` that puts
me in the patch file would set next-error-last-source-buffer to that patch
file buffer so hitting C-x ` in that patch file buffer would correctly
ignore the patch file buffer and use the compilation buffer instead.

BTW, it looks like the `avoid-current' argument is *never* used.

Any objection to the patch below?


        Stefan


--- simple.el	28 jui 2007 16:22:16 -0400	1.859.2.3
+++ simple.el	02 aoû 2007 12:17:20 -0400	
@@ -173,6 +173,9 @@
 similar mode is started, or when it is used with \\[next-error]
 or \\[compile-goto-error].")
 
+(defvar next-error-last-source-buffer nil
+  "The most recent buffer to which `next-error' jumped.")
+
 (defvar next-error-function nil
   "Function to use to find the next error in the current buffer.
 The function is called with 2 parameters:
@@ -228,14 +231,33 @@
 The function EXTRA-TEST-EXCLUSIVE, if non-nil, is called in each buffer
 that would normally be considered usable.  If it returns nil,
 that buffer is rejected."
+  ;; FIXME: It looks like the `avoid-current' argument is never used.
+  (let ((minor-avoid-current
+         (or avoid-current
+             ;; When a C-x ` in an occur or compilation buffer jumps to
+             ;; a patch file, we want the next C-x ` to keep visiting the
+             ;; next errors or occurrences, rather than jump to the
+             ;; next hunk.
+             (eq (current-buffer) next-error-last-source-buffer))))
   (or
+     ;; 0. If the current buffer is acceptable, choose it, unless it is the
+     ;;    buffer to which the last next-error jumped.
+     (if (next-error-buffer-p (current-buffer) minor-avoid-current
+                              extra-test-inclusive extra-test-exclusive)
+         (current-buffer))
    ;; 1. If one window on the selected frame displays such buffer, return it.
+     ;;    This takes precedence to the next-error-last-buffer so as to
+     ;;    try and address the situation where the user works on 2 projects
+     ;;    within the same Emacs session, does a C-x ` on a compilation in the
+     ;;    first project, then C-x ` on an occur buffer in the second, then
+     ;;    comes back to the first project and hits C-x ` expecting to jump to
+     ;;    the next error of the first project's compilation.
    (let ((window-buffers
           (delete-dups
            (delq nil (mapcar (lambda (w)
                                (if (next-error-buffer-p
 				    (window-buffer w)
-                                    avoid-current
+                                      minor-avoid-current
                                     extra-test-inclusive extra-test-exclusive)
                                    (window-buffer w)))
                              (window-list))))))
@@ -246,7 +268,9 @@
             (next-error-buffer-p next-error-last-buffer avoid-current
                                  extra-test-inclusive extra-test-exclusive))
        next-error-last-buffer)
-   ;; 3. If the current buffer is acceptable, choose it.
+     ;; 3. If the current buffer is acceptable, choose it.  This is only
+     ;;    useful if the current-buffer is the buffer to which the last
+     ;;    next-error jumped (otherwise rule 0 applied already).
    (if (next-error-buffer-p (current-buffer) avoid-current
 			    extra-test-inclusive extra-test-exclusive)
        (current-buffer))
@@ -267,7 +291,7 @@
 	  (message "This is the only buffer with error message locations")
 	  (current-buffer)))
    ;; 6. Give up.
-   (error "No buffers contain error message locations")))
+     (error "No buffers contain error message locations"))))
 
 (defun next-error (&optional arg reset)
   "Visit next `next-error' message and corresponding source code.
@@ -301,18 +325,21 @@
 \`compilation-error-regexp-alist' for customization ideas."
   (interactive "P")
   (if (consp arg) (setq reset t arg nil))
+  ;; This `when' is unneeded because next-error-find-buffer never returns nil.
   (when (setq next-error-last-buffer (next-error-find-buffer))
     ;; we know here that next-error-function is a valid symbol we can funcall
     (with-current-buffer next-error-last-buffer
       (funcall next-error-function (prefix-numeric-value arg) reset)
+      (setq next-error-last-source-buffer (current-buffer))
       (run-hooks 'next-error-hook))))
 
 (defun next-error-internal ()
   "Visit the source code corresponding to the `next-error' message at point."
   (setq next-error-last-buffer (current-buffer))
-  ;; we know here that next-error-function is a valid symbol we can funcall
-  (with-current-buffer next-error-last-buffer
+  ;; We know here that next-error-function is a valid symbol we can funcall.
+  (save-current-buffer
     (funcall next-error-function 0 nil)
+    (setq next-error-last-source-buffer (current-buffer))
     (run-hooks 'next-error-hook)))
 
 (defalias 'goto-next-locus 'next-error)

Re: next-error-find-buffer

[Ted Zlatanov]

On Thu, 02 Aug 2007 12:17:44 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> To remind people of the context, C-x ` has two problems:

SM> 1 - if you have two projects, do C-x ` in the first, then do C-x ` in the
SM>     second, and then come back to the first and do C-x ` again, you'd want
SM>     this C-x ` to use the compilation buffer of the first project, not of
SM>     the second one.  So you'd want to sometimes ignore
SM>     next-error-last-buffer.  This is the reason why "next-error capable
SM>     buffer in the current frame" currently takes precedence over
SM>     next-error-last-buffer.

SM> 2 - if you do C-x ` on a compilation buffer and that jumps to a patch file,
SM>     and then do C-x ` from that patch file's buffer, it should look for the
SM>     next error in the compilation buffer rather than the next hunk in the
SM>     patch file.
SM>     Currently this is done by giving precedence to next-error-last-buffer
SM>     over current-buffer (i.e. basically this always ignores
SM>     current-buffer.  In practice current-buffer is still often used because
SM>     of the first rule "next-error capable buffer in current frame").

SM> The way I use Emacs, I have one frame per buffer.  So the first rule
SM> basically means that current-buffer is always selected, so for me problem
SM> number 2 is not corrected.

SM> My original suggestion to fix number 2 was to introduce a new variable
SM> next-error-last-source-buffer which is set to the last source buffer visited
SM> by next-error.  Then C-x ` would ignore current-buffer (and obey
SM> next-error-last-buffer instead) if the current buffer is equal to
SM> next-error-last-source-buffer: in the example problem, the C-x ` that puts
SM> me in the patch file would set next-error-last-source-buffer to that patch
SM> file buffer so hitting C-x ` in that patch file buffer would correctly
SM> ignore the patch file buffer and use the compilation buffer instead.

I think your fix makes sense.  I've avoided work on next-error in the
past because of the recent release, but this was annoying behavior in
some cases.

I have some other proposals for the next/previous functionality, if
anyone is interested.  Basically I think it should be expanded to other
parts of Emacs, because it's so handy.

Ted

Re: next-error-find-buffer (was: kill-compilation failing when there are several compilation buffers)

[Richard Stallman]

    Actually, that thread did not conclude that the current set of rules is The
    Right Way.  It ignored my suggestion (which was to keep the
    `current-buffer' as the first rule, but to disable it if current-buffer was
    the last source buffer visited by next-error).

I can see how, in some situations, that would be better behavior
in next-error.  (My change is still needed for kill-compilation.)

However, it seems to me that there may be other situations were it
might be worse behavior.  This is the sort of issue where no solution
is clearly right, every choice is a heuristic, and there may not be
any best solution.

Since your change makes the code more complex, I think we should not
install it now.  Instead, people should try it, and we can see whether
they generally like it better.  If they do, then please install it.

Re: next-error-find-buffer

[Juri Linkov]

> My original suggestion to fix number 2 was to introduce a new variable
> next-error-last-source-buffer which is set to the last source buffer visited
> by next-error.  Then C-x ` would ignore current-buffer (and obey
> next-error-last-buffer instead) if the current buffer is equal to
> next-error-last-source-buffer: in the example problem, the C-x ` that puts
> me in the patch file would set next-error-last-source-buffer to that patch
> file buffer so hitting C-x ` in that patch file buffer would correctly
> ignore the patch file buffer and use the compilation buffer instead.
>
> Any objection to the patch below?

Perhaps a new variable next-error-last-source-buffer should be buffer-local.
I imagine such a test case: C-x ` on a grep buffer visits the patch file,
then in another frame on another grep buffer C-x ` visits its own patch file,
then I switch back to the first patch file, type C-x `, and it will fail
to visit the next grep hit from the first grep buffer, because the
global next-error-last-source-buffer is set now to the second patch
buffer from the second grep buffer.

Please note that I concluded this outcome only by looking at your patch.
I will try it for a few days to see how well it works in different cases.

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