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

["Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> We can help out.

To quote you, "That's the spirit!" :)

Please see the to-do comment I left in the 'compile-tests.el'.  I think
we want 'compile--test-error-line' to support both positive and negative
test cases.

> Only use non-greedy operators [...]

I updated everything to my best knowledge.  If the regexps are still not
good enough, please quote the problematic fragments, so that I know
exactly where the problem is.

> Maybe you should test it just in case. (You don't need a Windows
> machine to do that but it adds authenticity).

I do not understand.  Are you saying that the tests I wrote are
insufficient?  If so, could you please elaborate?

> Look, it's not a beauty contest. We'll do what we have to.

How do false positives and performance tie to "beauty"?  I must have
miscommunicated badly.  What I wanted to say is that I imagine Lua
working out of the box, hence my hunch for the most precise regexps.

>> We still detect the file path/name, which is useful.
>
> The point is that it substantially increases the risks of false
> matches. Lua needs to be a good neighbour and can't just think of its
> own needs over anything else.

The sequence of characters is fairly unique, given each stack frame must
start with a tab and then contain ": in " after the file name.

Rudy
-- 
"Programming reliably -- must be an activity of an undeniably
mathematical nature […] You see, mathematics is about thinking, and
doing mathematics is always trying to think as well as possible."
-- Edsger W. Dijkstra, 1981

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia