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

[Mattias Engdegård]

3 okt. 2023 kl. 10.12 skrev Rudolf Adamkovič <salutis@me.com>:

> +    (lua
> +     "^[^: \n\t]+: \\([^: \n\t]+\\):\\([0-9]+\\): " 1 2 nil 2 1)

This pattern matches some lines normally matched by the `gnu` rule which comes 
later in the rule list. I don't know if it's a big problem -- it may cause 
misclassification of some messages which should be of 'warning' or 'info' type.

> +    (lua-stack
> +     "^\t\\([^: \n\t]+\\):\\([0-9]+\\): " 1 2 nil 0 1)

I'm actually slightly more bothered by this message because it would conflict 
with possible future (re-)relaxation of the `gnu` rule with respect to leading 
whitespace. The matter does come up from time to time, and it would be nice to 
at least have the option to do that.

In addition, there's this:

> (B) People use older Lua versions, which will work forever, as they are
> written in ANSI C, and so even if (1) is fixed upstream, we must support
> the current error format as well.

This also means that we may need to support an open set of Lua message types.

What about adding these rules but not enabling them by default? Is that too 
onerous?

The 'omake' rule has now been disabled by default for other reasons (it's 
something that has been discussed in the past), so there is at least precedence 
for doing this.