Re: order of elements in compilation-error-regexp-alist

[Kevin Rodgers]

David Kuehling wrote:
> 
> Hi there!
> 
> I recently tried to customize `compilation-error-regexp-alist', for
> correctly recognizing errors of the form
> 
> Parsing...../home/user/file:1234: error
> 
> Although this error line is already matched by existing regexps in
> `compilation-error-regexp-alist', they took the prefix "Parsing...." as
> part of the file-name, which is not what I want.
> 
> By adding a new element to the front of the list
> (`("^\\(Parsing\\.+\\)?\\([^:\n]+\\):\\([0-9]+\\):
> \\(error\\|warning\\)" 2 3)'), errors were hilighted correctly, but
> `compile-goto-error' seemed to use one of the bad regexps, that include
> "Parsing..." in the file name. By adding the new element to the end of
> the list, `compile-goto-error' worked correctly, but hilighting was
> wrong.
> 
> This inconsitency looks like a bug to me. It would also be helpful if
> the order of precedence of elements in `compilation-error-regexp-alist'
> was documented.

Indeed, but we should be able to fix the bug instead of documenting it.

Does the problem still occur if you omit the leading "^" in your regexp?
(compilation-mode-font-lock-keywords has code to "Prepend "^", adjusting
FILE-IDX and LINE-IDX accordingly.")

Also, compile-collect-regexps (which is called by compilation-parse-errors),
cdr's down its THIS argument and adds each element to the front  of
compilation-regexps, effectively reversing the order of the entries in
compilation-error-regexp-alist.

-- 
Kevin Rodgers <kevinr@ihs.com>