[PATCH] Handle output from Emacs byte-compilation properly

[PATCH] Handle output from Emacs byte-compilation properly

[Jostein Kjønigsen]

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

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

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

- 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 which doesn't exist.

This is due to the following regexp, which is quite frankly extremely
wide:

    (guile-file "^In \\(.+\\):\n" 1)

This breaks prev-error and next-error based navigation because the
files "toplevel form" and "end of data" doesn't exist.

This patch ensures those lines are treated as information only before
getting to the guile-file regexp.

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

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

From eec1a7951b0bfb85875ef09f1d78988068893c06 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jostein=20Kj=C3=B8nigsen?= <jostein@kjonigsen.net>
Date: Mon, 14 Sep 2015 21:43:57 +0200
Subject: [PATCH] Handle output from Emacs byte-compilation properly

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

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

- 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 ensures those lines are treated as information only before
getting to the guile-files regexp.
---
 lisp/progmodes/compile.el | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index a6e9ed8..c936ec6 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -477,6 +477,12 @@ File = \\(.+\\), Line = \\([0-9]+\\)\\(?:, Column = \\([0-9]+\\)\\)?"
      ;;
      "^\\([^ \t\r\n(]+\\) (\\([0-9]+\\):\\([0-9]+\\)) "
      1 2 3)
+
+    ;; ensure emacs-info headers are not treated as guile-errors.
+    ;; created using (rx (or "In toplevel form:" "In end of data:"))
+    (add-to-list 'compilation-error-regexp-alist-alist '(elisp-info "\\(?:In \\(?:\\(?:end of data\\|toplevel form\\):\\)\\)" nil nil nil 0))
+    (add-to-list 'compilation-error-regexp-alist 'elisp-info)
+
     (guile-file "^In \\(.+\\):\n" 1)
     (guile-line "^ *\\([0-9]+\\): *\\([0-9]+\\)" nil 1 2)
     )
--
1.9.1

Re: [PATCH] Handle output from Emacs byte-compilation properly

[Jostein Kjønigsen]

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

The previous patch is not  a good one and there's an error in it. Please
disregard
the previous patch and consider the attached patch instead.

You'll have to take my word for it when I say I -did- test it before
submitting. :)

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


On Mon, Sep 14, 2015, at 10:14 PM, Jostein Kjønigsen wrote:
> It's common for module-developers to run Emacs byte-compilation in
> separate build-scripts.
> 
> When invoking byte-compile on Emacs-lisp files you often get the
> following headers:
> 
> - 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 which doesn't exist.
> 
> This is due to the following regexp, which is quite frankly extremely
> wide:
> 
>     (guile-file "^In \\(.+\\):\n" 1)
> 
> This breaks prev-error and next-error based navigation because the
> files "toplevel form" and "end of data" doesn't exist.
> 
> This patch ensures those lines are treated as information only before
> getting to the guile-file regexp.
> 
> --
> Jostein Kjønigsen
> jostein@kjonigsen.net / jostein@secure.kjonigsen.net
> Email had 1 attachment:


> * compilation-mode-emacs-lisp.patch
>   2k (text/x-patch)

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

From 8a2c39dcd3d2609f571eae9fa1a16d34dba91f3c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jostein=20Kj=C3=B8nigsen?= <jostein@kjonigsen.net>
Date: Mon, 14 Sep 2015 21:43:57 +0200
Subject: [PATCH] Handle output from Emacs byte-compilation properly

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

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

- 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 ensures those lines are treated as information only before
getting to the guile-files regexp.
---
 lisp/progmodes/compile.el | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index a6e9ed8..cb5c884 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -477,6 +477,11 @@ File = \\(.+\\), Line = \\([0-9]+\\)\\(?:, Column = \\([0-9]+\\)\\)?"
      ;;
      "^\\([^ \t\r\n(]+\\) (\\([0-9]+\\):\\([0-9]+\\)) "
      1 2 3)
+
+    ;; ensure emacs-info headers are not treated as guile-errors.
+    ;; created using (rx (or "In toplevel form:" "In end of data:"))
+    (elisp-info "\\(?:In \\(?:\\(?:end of data\\|toplevel form\\):\\)\\)" nil nil nil 0)
+
     (guile-file "^In \\(.+\\):\n" 1)
     (guile-line "^ *\\([0-9]+\\): *\\([0-9]+\\)" nil 1 2)
     )
-- 
1.9.1

Re: [PATCH] Handle output from Emacs byte-compilation properly

[Jostein Kjønigsen]

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

Trying to byte-compile csharp-mode I get a lot of different headers
which are
caught by the guile-file compilation-error-regexp-alist-alist entry.
(See attached
file)

It seems obvious to me now that I cannot patch every possible scenario
which
may incorrectly get picked up by guile-file as an error.

The fix for this problem must come from making guile-file more selective
and specific. Right now it's too wide and causing issues for other
languages.

Jan:
Would it be possible to fix that regexp to be more constrained? Maybe
only
trigger for certain extensions? I'm not deeply into Guile or Scheme, so
I'm
not which extensions are common and in use.

Would constraining it to *.scm be sufficient?

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


On Mon, Sep 14, 2015, at 10:24 PM, Jostein Kjønigsen wrote:
> The previous patch is not  a good one and there's an error in it. Please
> disregard
> the previous patch and consider the attached patch instead.
> 
> You'll have to take my word for it when I say I -did- test it before
> submitting. :)
> 
> --
> Jostein Kjønigsen
> jostein@kjonigsen.net / jostein@secure.kjonigsen.net
> 
> 
> On Mon, Sep 14, 2015, at 10:14 PM, Jostein Kjønigsen wrote:
>> It's common for module-developers to run Emacs byte-compilation in
>> separate build-scripts.
>> 
>> When invoking byte-compile on Emacs-lisp files you often get the
>> following headers:
>> 
>> - 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 which doesn't exist.
>> 
>> This is due to the following regexp, which is quite frankly extremely
>> wide:
>> 
>>     (guile-file "^In \\(.+\\):\n" 1)
>> 
>> This breaks prev-error and next-error based navigation because the
>> files "toplevel form" and "end of data" doesn't exist.
>> 
>> This patch ensures those lines are treated as information only before
>> getting to the guile-file regexp.
>> 
>> --
>> Jostein Kjønigsen
>> jostein@kjonigsen.net / jostein@secure.kjonigsen.net
>> Email had 1 attachment:
> 
> 
>> * compilation-mode-emacs-lisp.patch
>>   2k (text/x-patch)
> Email had 1 attachment:


> * compilation-mode-emacs-lisp.patch
>   2k (text/x-patch)

[-- Attachment #2: csharp-mode-compilation-output.txt --]
[-- Type: text/plain, Size: 1120 bytes --]

26 matches for "In " in buffer: *compilation*
     10:In csharp--at-vsemi-p:
     14:In csharp--move-back-to-beginning-of-something:
     20:In csharp-move-back-to-beginning-of-defun:
     26:In csharp--on-defun-close-curly-p:
     34:In csharp--on-ctor-close-curly-p:
     38:In csharp--on-class-close-curly-p:
     44:In csharp--on-intf-close-curly-p:
     48:In csharp--on-enum-close-curly-p:
     52:In csharp--on-namespace-close-curly-p:
     56:In csharp--on-defun-open-curly-p:
     64:In csharp--on-class-open-curly-p:
     70:In csharp--on-genclass-open-curly-p:
     74:In csharp--on-namespace-open-curly-p:
     78:In csharp--on-ctor-open-curly-p:
     82:In csharp--on-intf-open-curly-p:
     86:In csharp--on-prop-open-curly-p:
     92:In csharp--on-indexer-open-curly-p:
     96:In csharp--on-enum-open-curly-p:
    100:In csharp-move-fwd-to-end-of-defun:
    104:In csharp-move-back-to-beginning-of-class:
    110:In csharp-move-back-to-beginning-of-namespace:
    114:In csharp--imenu-create-index-helper:
    128:In csharp-mode:
    134:In end of data:
    145:In toplevel form:
    155:In end of data:

Re: [PATCH] Handle output from Emacs byte-compilation properly

[Stefan Monnier]

> The fix for this problem must come from making guile-file more selective
> and specific. Right now it's too wide and causing issues for other
> languages.

Agreed.  Also, it probably should be have its importance reduced from
"error" to "info".  Can you make a bug report for that (via M-x
report-emacs-bug) so we get a bug number for it.


        Stefan