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

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

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