GNU bug report logs - #60830
30.0.50; The *Compilation* buffer does not recognize Lua errors

Previous Next

Full log

Message #99 received at 60830 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 60830 <at> debbugs.gnu.org, Rudolf Adamkovič <salutis <at> me.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#60830: 30.0.50; The *Compilation* buffer does not recognize
 Lua errors
Date: Wed, 10 Jan 2024 18:45:24 +0100

10 jan. 2024 kl. 18.09 skrev Stefan Kangas <stefankangas <at> gmail.com>:

> Sorry, that was a misunderstanding on my part.  I thought we were done
> discussing it.  Feel free to revert the change and reopen the bug, or
> whatever else you think makes sense here.

No, I think we're done with the bug at hand (Lua messages) for now, even if it means that we may revisit the choices made later on.

> How about adding a new user option `compilation-enabled-errors' where
> you could disable (or enable) the ones you are interested in, and then
> generate `compilation-error-regexp-alist-alist' based on that?

See the (somewhat lengthy) history of this bug for some discussion about that. In short, we already have `compilation-error-regexp-alist` which basically serves that purpose, but is complicated by the fact that both users and packages edit it and `compilation-error-regexp-alist-alist`, often at the same time.

The question is how we can reinterpret CERA and CERAA in a compatible way that allows for easy user customisation but also for them to be extended in a modular way.

>> (And it's probably high time I made a batch conversion of the
>> remaining patterns to rx.)
> 
> That would help maintenance, so I'm all for it.

I'll do that a little later then.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.