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

Previous Next

Package: emacs;

Reported by: Rudolf Adamkovič <salutis <at> me.com>

Date: Sun, 15 Jan 2023 11:35:01 UTC

Severity: wishlist

Found in version 30.0.50

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Rudolf Adamkovič <salutis <at> me.com>
Cc: Mattias Engdegård <mattias.engdegard <at> gmail.com>, 60830 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors
Date: Sun, 08 Oct 2023 11:49:03 -0400
> (1) How can I specify "this group cannot be '[C]'" in the regexp?

For true "regular expressions", you'd use conjunction and negation and
Bob's your uncle, but sadly, our regexps don't support conjunction nor
negation, so you're stuck doing it by hand, e.g.:

    "\\|\\[\\|[^[].*\\|\\[C\\|\\[[^C].*\\|\\[C[^]].*\\|\\[C].+"

Yes, it's hideous and it suffers from a really bad size-explosion
syndrome.  I don't even want to think about how to encode "this group
can match neither "joe" nor "henry".

>> I see no reason for the non-greedy match in the first regexp, do you?
> I made the relevant groups greedy, but I wonder what difference it
> makes.  Is there a way to test the change in 'compile-tests.el'?

    .*?\n

and

    .*\n

are equivalent because . can't match the same char as \n, so there's no
choice to be made about how many repetitions of . to use.

But the regexp compiler notices this fact (which it can use to avoid
using backtracking and thus work noticeably more efficiently) only if
you use ".*\n".


        Stefan





This bug report was last modified 1 year and 211 days ago.

Previous Next


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