bug#58984: 29.0.50; M-x compile misinterprets libcheck error message format

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

8 nov. 2022 kl. 19.24 skrev Basil L. Contovounesios <contovob@tcd.ie>:

> I'd have to look at the source and search their past discussions; it's
> possible this has come up before.  Don't hold your breath though,
> because I won't get around to this soon.  Either way I wouldn't be
> particularly comfortable asking to change a default format that's
> presumably been around for a while, but perhaps they can advise us
> indeed.

Yes, we usually prefer working with upstream tool developers whenever possible, rather than adapting to yet another quirky message format.
Let's not assume their format is that way by design; it could just be a simple oversight.

> Does it have to go in the 'gnu' rule?  Is it not feasible to have it as
> a separate rule?

That's a good point and it clearly can be a separate rule, but should that rule be added to the way-too-long list of patterns in Emacs or something that libcheck users need to add? Or should we include it but disabled by default?

(And would the new rule have to cope with spaces and colons in file names, duplicating most of the messiness of the gnu rule?)

Each time another rule is added to compilation-error-regexp-alist-alist I hold my breath, watching the now slightly taller tower sway uneasily...

An alternative is to post-process the output of the command that emits these messages -- a simple sed command might do.