bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

6 okt. 2023 kl. 16.47 skrev Stefan Monnier <monnier@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.