Dealing with "gnu" rule in compilation-error-regexp-alist

Dealing with "gnu" rule in compilation-error-regexp-alist

[Wilson Snyder]

I'm trying to debug a problem with a compile error regexp.  An
example is below; the highlighting may look correct, but
next-error will bring you to the wrong filename.  (I'm using the
HEAD, but the same issue exists since Emacs 21.)

What's going on is the "gnu" rule is trumping the "percent" rule
- if you look at the comments for the "gnu" rule in compile.el,
it been hacked to reduce aggressiveness several times before.

What do people suggest to work around this problem?  When compile
is called from inside the package-mode's buffer it could
subtract "gnu" from compilation-error-regexp-alist, but that
seems very unfriendly, and hard for users to debug.  Likewise
tweaking the "gnu" rule makes a mess, as there's really several
regexps causing the problem.

The solution needs to work with the already released versions of
Emacs too.

Long term, I think it would be good have some sort of
ordering or priority to the rules; "gnu" being low priority,
without breaking the later fontification rules (why these
rules "append" now).

Thanks

(setq compilation-error-regexp-alist-alist
      (append
       '((percent "%?\\(Error\\|Warning\\):[\n ]*\\([^ \t:]+\\):\\([0-9]+\\):" 2 3))
       compilation-error-regexp-alist-alist))
;; Ok
(setq compilation-error-regexp-alist '(percent))
(compile "echo 'zz: %Error: foo.x:1: something'")
(compile "echo '%Error: foo.x:1: something'")
;; Bad
(setq compilation-error-regexp-alist '(gnu percent))
(compile "echo 'zz: %Error: foo.x:1: something'")
;; Bad
(setq compilation-error-regexp-alist '(percent gnu))
(compile "echo 'zz: %Error: foo.x:1: something'")

Re: Dealing with "gnu" rule in compilation-error-regexp-alist

[Chong Yidong]

wsnyder@wsnyder.org (Wilson Snyder) writes:

> (setq compilation-error-regexp-alist-alist
>       (append
>        '((percent "%?\\(Error\\|Warning\\):[\n ]*\\([^ \t:]+\\):\\([0-9]+\\):" 2 3))
>        compilation-error-regexp-alist-alist))
> ;; Ok
> (setq compilation-error-regexp-alist '(percent))
> (compile "echo 'zz: %Error: foo.x:1: something'")
> (compile "echo '%Error: foo.x:1: something'")
> ;; Bad
> (setq compilation-error-regexp-alist '(percent gnu))
> (compile "echo 'zz: %Error: foo.x:1: something'")

You need to anchor your regexp at the start of the line.  For example,

   "^[^%\n]*%?\\(Error\\|Warning\\):[\n ]*\\([^ \t:]+\\):\\([0-9]+\\):" 2 3))

> Long term, I think it would be good have some sort of
> ordering or priority to the rules.

This is already the case.

Re: Dealing with "gnu" rule in compilation-error-regexp-alist

[Wilson Snyder]

>wsnyder@wsnyder.org (Wilson Snyder) writes:
>
>> (setq compilation-error-regexp-alist-alist
>>       (append
>>        '((percent "%?\\(Error\\|Warning\\):[\n ]*\\([^ \t:]+\\):\\([0-9]+\\):" 2 3))
>>        compilation-error-regexp-alist-alist))
>> ;; Ok
>> (setq compilation-error-regexp-alist '(percent))
>> (compile "echo 'zz: %Error: foo.x:1: something'")
>> (compile "echo '%Error: foo.x:1: something'")
>> ;; Bad
>> (setq compilation-error-regexp-alist '(percent gnu))
>> (compile "echo 'zz: %Error: foo.x:1: something'")
>
>You need to anchor your regexp at the start of the line.  For example,
>
>   "^[^%\n]*%?\\(Error\\|Warning\\):[\n ]*\\([^ \t:]+\\):\\([0-9]+\\):" 2 3))

Unfortunately I had already tried that.  It looks better for
the example I sent but doesn't solve more complicated
patterns.

>> Long term, I think it would be good have some sort of
>> ordering or priority to the rules.
>
>This is already the case.

Can you describe how to use it then?  Sorry I missed it - I
followed the code and it seems to just do a mapcar to build
the font-lock list and always uses 'append, so font-lock
will keep processing.

-Wilson

Re: Dealing with "gnu" rule in compilation-error-regexp-alist

[Stefan Monnier]

> What do people suggest to work around this problem?

The Right Way is to get the tool to use the GNU format for its
error messages.

> When compile is called from inside the package-mode's buffer it could
> subtract "gnu" from compilation-error-regexp-alist, but that seems
> very unfriendly, and hard for users to debug.

Not knowing how your "package-mode" is typically used, I can't judge
whether messages from other tools are likely to appear there as well.

> Likewise tweaking the "gnu" rule makes a mess, as there's really
> several regexps causing the problem.

The patch below tweaks it in a way which seems to solve your problem.

> The solution needs to work with the already released versions of
> Emacs too.

;-)

> Long term, I think it would be good have some sort of
> ordering or priority to the rules; "gnu" being low priority,
> without breaking the later fontification rules (why these
> rules "append" now).

Supposedly there is such a priority based on ordering.

> (setq compilation-error-regexp-alist '(percent gnu))
> (compile "echo 'zz: %Error: foo.x:1: something'")

E.g. from what I understand the above *should* work, so there's maybe
a bug lurking here.


        Stefan


=== modified file 'lisp/progmodes/compile.el'
--- lisp/progmodes/compile.el	2010-04-11 03:41:47 +0000
+++ lisp/progmodes/compile.el	2010-04-15 18:44:06 +0000
@@ -253,9 +253,9 @@
      ;; The core of the regexp is the one with *?.  It says that a file name
      ;; can be composed of any non-newline char, but it also rules out some
      ;; valid but unlikely cases, such as a trailing space or a space
-     ;; followed by a -.
+     ;; followed by a -, or a colon followed by a space.
      "^\\(?:[[:alpha:]][-[:alnum:].]+: ?\\)?\
-\\([0-9]*[^0-9\n]\\(?:[^\n ]\\| [^-/\n]\\)*?\\): ?\
+\\([0-9]*[^0-9\n]\\(?:[^\n :]\\| [^-/\n]\\|:[^ \n]\\)*?\\): ?\
 \\([0-9]+\\)\\(?:\\([.:]\\)\\([0-9]+\\)\\)?\
 \\(?:-\\([0-9]+\\)?\\(?:\\.\\([0-9]+\\)\\)?\\)?:\
 \\(?: *\\(\\(?:Future\\|Runtime\\)?[Ww]arning\\|W:\\)\\|\