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

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

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.