bug#70794: 30.0.50; Add Rust compilation regex

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

3 juni 2024 kl. 17.28 skrev Eli Zaretskii <eliz@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.