bug#21496: 25.0.50; guile-file compilation-error regexp is too wide

["Jostein Kjønigsen" <jostein@secure.kjonigsen.net>]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

See updated patch. It should address all concerns raised so far.

To my knowledge I have not filled in any FSF copyright assignment
papers yet, so I assume that will be next on my list of tasks to
complete. I proceed with that independently of this bug.

Stefan: Do you need to be kept on CC for that process, or is
everything else OK?

--
Jostein Kjønigsen
jostein@kjonigsen.net / jostein@secure.kjonigsen.net


On Sun, Sep 20, 2015, at 05:20 PM, Stefan Monnier wrote:
>> - Reduce severity from error to warning.
> 
> There are 3 levels: error, warning, and info.  It's currently set as
> "error" and it should be "info".
> 
>> +    ;; file-entries does not have to be errors, treat as info.
>> +    (guile-file "^In \\(.+\\..+\\):\n" 1 nil nil 0)
> 
> Please move the discussion about the ambiguity problem from the commit
> message to a comment here, so that it's visible even if you don't pay
> attention to the VCS's metadata.
> 
> 
>         Stefan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Emacs-compilation-mode-fixes.patch --]
[-- Type: text/x-patch; name="Emacs-compilation-mode-fixes.patch", Size: 2415 bytes --]

From 485776784a12d094f4148ae79cc42140c66a619f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jostein=20Kj=C3=B8nigsen?= <jostein@kjonigsen.net>
Date: Sun, 20 Sep 2015 09:39:50 +0200
Subject: [PATCH] Emacs: compilation-mode fixes.

It's common for Emacs-lisp module-developers to run Emacs
byte-compilation in separate build-scripts.

When invoking byte-compile on Emacs-lisp files you often get headers
like:

- In toplevel form:
- In end of data:

When these errors show up in the output of a build-script initiated
through M-x compile and show up in a compilation-mode buffer, these
lines gets treated as guile-errors for files with the respective names
"toplevel form" and "end of data".

This breaks prev-error and next-error based navigation.

This patch fixes this by doing the following modifications:

- Make guile-file only trigger on files with an extension.
- Reduce severity from error to info.
---
 lisp/progmodes/compile.el | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index f9c097e..9cb367a 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -477,7 +477,29 @@ File = \\(.+\\), Line = \\([0-9]+\\)\\(?:, Column = \\([0-9]+\\)\\)?"
      ;;
      "^\\([^ \t\r\n(]+\\) (\\([0-9]+\\):\\([0-9]+\\)) "
      1 2 3)
-    (guile-file "^In \\(.+\\):\n" 1)
+
+    ;; Guile compilation yields file-headers in the following format:
+    ;;
+    ;;   In sourcefile.scm:
+    ;;
+    ;; We need to catch those, but we also need to be aware that Emacs
+    ;; byte-compilation yields compiler headers in similar form of
+    ;; those:
+    ;;
+    ;;   In toplevel form:
+    ;;   In end of data:
+    ;;
+    ;; We want to catch the Guile file-headers but not the Emacs
+    ;; byte-compilation headers, because that will cause next-error
+    ;; and prev-error to break, because the files "toplevel form" and
+    ;; "end of data" does not exist.
+    ;;
+    ;; To differentiate between these two cases, we require that the
+    ;; file-match must always contain an extension.
+    ;;
+    ;; We should also only treat this as "info", not "error", because
+    ;; we do not know what lines will follow.
+    (guile-file "^In \\(.+\\..+\\):\n" 1 nil nil 0)
     (guile-line "^ *\\([0-9]+\\): *\\([0-9]+\\)" nil 1 2)
     )
   "Alist of values for `compilation-error-regexp-alist'.")
-- 
2.1.4