unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* [PATCH] Handle output from Emacs byte-compilation properly
@ 2015-09-14 20:14 Jostein Kjønigsen
  2015-09-14 20:24 ` Jostein Kjønigsen
  0 siblings, 1 reply; 4+ messages in thread
From: Jostein Kjønigsen @ 2015-09-14 20:14 UTC (permalink / raw)
  To: emacs-devel; +Cc: Jan Nieuwenhuizen

[-- 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


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] Handle output from Emacs byte-compilation properly
  2015-09-14 20:14 [PATCH] Handle output from Emacs byte-compilation properly Jostein Kjønigsen
@ 2015-09-14 20:24 ` Jostein Kjønigsen
  2015-09-15  9:57   ` Jostein Kjønigsen
  0 siblings, 1 reply; 4+ messages in thread
From: Jostein Kjønigsen @ 2015-09-14 20:24 UTC (permalink / raw)
  To: emacs-devel; +Cc: Jan Nieuwenhuizen

[-- 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



^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] Handle output from Emacs byte-compilation properly
  2015-09-14 20:24 ` Jostein Kjønigsen
@ 2015-09-15  9:57   ` Jostein Kjønigsen
  2015-09-15 16:03     ` Stefan Monnier
  0 siblings, 1 reply; 4+ messages in thread
From: Jostein Kjønigsen @ 2015-09-15  9:57 UTC (permalink / raw)
  To: emacs-devel; +Cc: Jan Nieuwenhuizen

[-- 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:

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Handle output from Emacs byte-compilation properly
  2015-09-15  9:57   ` Jostein Kjønigsen
@ 2015-09-15 16:03     ` Stefan Monnier
  0 siblings, 0 replies; 4+ messages in thread
From: Stefan Monnier @ 2015-09-15 16:03 UTC (permalink / raw)
  To: Jostein Kjønigsen; +Cc: Jan Nieuwenhuizen, jostein, emacs-devel

> 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



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-09-15 16:03 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-14 20:14 [PATCH] Handle output from Emacs byte-compilation properly Jostein Kjønigsen
2015-09-14 20:24 ` Jostein Kjønigsen
2015-09-15  9:57   ` Jostein Kjønigsen
2015-09-15 16:03     ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).