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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ergus <spacibba <at> aol.com>
Cc: 70794 <at> debbugs.gnu.org, mattias.engdegard <at> gmail.com
Subject: bug#70794: 30.0.50; Add Rust compilation regex
Date: Tue, 04 Jun 2024 17:33:19 +0300

> Date: Tue, 4 Jun 2024 00:36:17 +0200
> From: Ergus <spacibba <at> aol.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 70794 <at> debbugs.gnu.org
> 
> On Mon, Jun 03, 2024 at 06:22:48PM GMT, Mattias Engdeg�rd wrote:
> >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.
> >
> About this, I may say that IMO the best approach is to use lazy insertion
> with-eval-after-load.

That's orthogonal, and I'm not sure I agree with you.

In any case, it only lowers the probability of clashes, but doesn't
resolve them.  Moreover, it makes the problems harder to reproduce
(because now they will depend on the order of previous commands).

Previous Next

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