[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: |
Fri, 6 Oct 2023 18:20:45 +0200 |
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.
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, (continued)
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Stefan Kangas, 2023/10/02
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Rudolf Adamkovič, 2023/10/03
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Mattias Engdegård, 2023/10/05
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Rudolf Adamkovič, 2023/10/05
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Mattias Engdegård, 2023/10/06
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Stefan Monnier, 2023/10/06
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Mattias Engdegård, 2023/10/06
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Stefan Monnier, 2023/10/06
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors,
Mattias Engdegård <=
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Stefan Monnier, 2023/10/06
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Mattias Engdegård, 2023/10/07
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Stefan Monnier, 2023/10/07
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Mattias Engdegård, 2023/10/08
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Mattias Engdegård, 2023/10/08
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Rudolf Adamkovič, 2023/10/07
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Mattias Engdegård, 2023/10/08
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Rudolf Adamkovič, 2023/10/12
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Rudolf Adamkovič, 2023/10/12
- bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors, Mattias Engdegård, 2023/10/12