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

Previous Next

Full log

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

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

6 okt. 2023 kl. 16.47 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:

> No, I do mean the ordering in CERA: is there a reason not to use this
> ordering to lower the precedence of those Lua rules instead of
> disabling them?

I'd say keeping rules active but placed where they never or only sometimes match can be seen as the worst of all choices: there is no indication that they are essentially inactive but things don't work right, and they still consume CPU.

What about powering ahead in the other direction and disable a whole lot of rarely-used rules? (No shortage of those.) Perhaps we could make a nicer interface for discovery and selection of available rules. The natural way is selecting a subset, not composing a list.

The rule names aren't ideal either and tell the user very little. We could augment each rule with a short description and an example of what they match, and perhaps information about rules that conflict.

> Admittedly, there is a performance cost to having all those big regexps
> active "just in case".  

Yes, and the number keeps growing so unless we start removing or disabling ones, it's only getting worse.

> I wonder is we could come
> with a way to figure out tell tale signs that particular tools might be
> (or can't be) used.

I can think of some dodgy heuristics that will make nobody happy but that's it.

Previous Next

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