bug#18109: 24.4.50; `compilation-error-regexp-alist-alist': wrong regexp for Maven

["Mattias Engdegård" <mattiase@acm.org>]

7 dec. 2020 kl. 21.07 skrev Filipp Gunbin <fgunbin@fastmail.fm>:

> [...] I have a feeling that few in Java world care about how the
> error parses in Emacs).

Most likely. On the other hand, lack of interest in the output format can also imply that it's unlikely to change.

> I doubt that any modern-or-so Java IDE will parse any error messages,
> given that build tools and compilers have APIs.

Quite possible, but the very emission of formalised messages to stdout/stderr means that this mode of usage is still acknowledged as somewhat common and useful.

> - did we have really that much problems caused by bad
> performance of compilation regexps?  Because if we did, then maybe we
> should look at other approaches, like trying to detect the compiler
> used, and narrow the set of regexps based on it.

This is hard to do in any practical way, not the least because a single message buffer may consist of the combined output of dozens of different tools -- compilers, linters, build tools, spell checkers, testing, stack traces, packaging, and so on. Not to mention the practical difficulty of going from the string 'make' to 'GCC version 11.2'.

That things work reasonably anyway is very much thanks to the prevalence of a few fairly common formats, such as GNU (file:line: message).

>  It's natural to expect
> that many different people would edit these regexps when something
> doesn't work for them, and expecting that you will always come and fix
> the things up would not be very fair to you :-)

Very considerate, thank you! There seems to be a fairly good flow of reports when something doesn't work. (A more modern and inviting bug-reporting system would probably help but that is a completely different matter.)

I'm pushing the proposed tightening of gradle-kotlin because the principle is right, and even if the Java world internally prefer APIs for composing tools, a tighter regexp in Emacs helps performance and accuracy for other patterns. Loose regexps form a sort of tragedy of the commons.

It seems that we also have forgotten to close the bug; doing that now. Thank you again for the insightful comments!