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

Previous Next

Full log

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

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

3 okt. 2023 kl. 10.12 skrev Rudolf Adamkovič <salutis <at> 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.

Previous Next

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