[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua erro
From: |
Mattias Engdegård |
Subject: |
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@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.