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


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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 60830 <at> debbugs.gnu.org, Rudolf Adamkovič <salutis <at> me.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#60830: 30.0.50; The *Compilation* buffer does not recognize
 Lua errors
Date: Wed, 10 Jan 2024 09:09:11 -0800
Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

> 10 jan. 2024 kl. 14.48 skrev Stefan Kangas <stefankangas <at> gmail.com>:
>
>> Thank you, installed on master (cd0eb055fd4) and closing the bug.
>
> Sorry for falling behind on this bug, and thank you for helping me
> catch up.
>
> However I wasn't actually finished here: the new regexps are still
> annoyingly close to other patterns that mismatches and/or bad
> performance cannot be ruled out, and it would be good to have a way to
> deal with it.

Sorry, that was a misunderstanding on my part.  I thought we were done
discussing it.  Feel free to revert the change and reopen the bug, or
whatever else you think makes sense here.

> I'm tempted go about disabling large swaths of rules since for every
> useful contemporary rule like Gnu, Typescript and yes, Lua, there seem
> to be a half-dozen ones for niche and/or outright antiquated tools.
>
> Anyway, I performed some minimum maintenance on the new Lua patterns
> but can't promise that they be enabled by default in the end -- it's
> not that they aren't useful but risk of interference.

If we can't even enable new patterns due to risk of interference, then
it's clear that we've dug ourselves into a hole.

How about adding a new user option `compilation-enabled-errors' where
you could disable (or enable) the ones you are interested in, and then
generate `compilation-error-regexp-alist-alist' based on that?  That
would provide a convenient way for users to get back the support for
their trusty Jikes compiler or whatever.  We should probably also
support using it as a directory local variable somehow, so that projects
could set this only once.

> (And it's probably high time I made a batch conversion of the
> remaining patterns to rx.)

That would help maintenance, so I'm all for it.




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.