GNU bug report logs - #70794
30.0.50; Add Rust compilation regex

Previous Next

Package: emacs;

Reported by: Ergus <spacibba <at> aol.com>

Date: Mon, 6 May 2024 01:31:01 UTC

Severity: normal

Found in version 30.0.50

Done: Mattias EngdegÄrd <mattias.engdegard <at> gmail.com>

Full log


View this message in rfc822 format

From: Mattias EngdegÄrd <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70794 <at> debbugs.gnu.org, spacibba <at> aol.com
Subject: bug#70794: 30.0.50; Add Rust compilation regex
Date: Mon, 3 Jun 2024 18:22:48 +0200
3 juni 2024 kl. 17.28 skrev Eli Zaretskii <eliz <at> gnu.org>:

> The order of the patterns in the alist is a complete mystery to me.  I
> tried to figure it out, but eventually gave up.  A remark won't cut
> it, I think: we need a detailed description of the principles,
> considerations, and the way of testing the results after adding a new
> pattern.

Yes, it's really not ideal. There are lots of legacy entries which are hardly ever used and just shouldn't be there, or at least not enabled by default. And as you say, the order is chaotic, difficult to understand, and probably not the best.

There is also insufficient testing of cross-pattern interference which isn't easy or cheap to do if we are serious about it.

The customisation interface is also not helping very much, and the whole mechanism is not very modular.

>> In fact the added pattern has visibly wrecked the display of etc/compilation.txt so I'm taking the slightly drastic step of reverting it.
> 
> That succeeded in my testing, so I wonder why it doesn't work for you.

My guess it is because of the nondeterministic parsing by compilation-mode; it seems to depend on the order of fontification, and possibly user settings (faces maybe). I can reproduce it reliably here, though.

Anyway, the syndrome was just a consequence of the previous observations about the (far too unrestrained) regexp, so there is no real mystery.

> If you revert it, please fix this ASAP and install the results, since
> I'd like to have this on the emacs-20 branch, which will be cut
> soon-ish.

Personally I strongly prefer no rule to a broken one, or even to Mattias's-best-guess-of-what-a-correct-rule-might-look-like.





This bug report was last modified 23 days ago.

Previous Next


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