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

Previous Next

Full log

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

From: Ergus <spacibba <at> aol.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 70794 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#70794: 30.0.50; Add Rust compilation regex
Date: Tue, 4 Jun 2024 00:36:17 +0200

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.

For example, as I mentioned when I opened the issue: I have this in my
init file:

```
(with-eval-after-load 'rust-ts-mode
  (with-eval-after-load 'compile
    (add-to-list
     'compilation-error-regexp-alist-alist
     `(cargo
       "^\\(?:\\(?4:error\\)\\|\\(?5:warning\\)\\)\\(?:\\[.+\\]\\)?:[^\0]+?--> \\(?1:[^:]+\\):\\(?2:[[:digit:]]+\\):\\(?3:[[:digit:]]+\\)"
       1 2 3 (5)
       nil
       (5 compilation-warning-face)
       (4 compilation-error-face)))

    (add-to-list 'compilation-error-regexp-alist 'cargo)))

```

I use something similar for other build tools (like msbuild or
incredibuild) in order to avoid performance impact.

I also apply some tricks to reduce the compilation-error-regexp-alist
when I know that only one pattern may apply in my cases. It may be
amazing if we could simplify such customizations/optimizations somehow...

>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.
>

Previous Next

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