bug#70794: 30.0.50; Add Rust compilation regex

bug#70794: 30.0.50; Add Rust compilation regex

[Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi:

Recently working with rust I have noticed that emacs does not recognizes
the rust/cargo error patterns.

Considering that emacs has now the rust-ts-mode, it may worth adding
the rust/cargo error patterns to compile when using that mode

In my system so far I have this:

```
(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)))

```

Maybe a more frequent rust user has a more general regex to
recommend. But this one works for me.

WDYT?

bug#70794: 30.0.50; Add Rust compilation regex

[Eli Zaretskii]

> Date: Mon, 06 May 2024 03:28:43 +0200
> From:  Ergus via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Recently working with rust I have noticed that emacs does not recognizes
> the rust/cargo error patterns.
> 
> Considering that emacs has now the rust-ts-mode, it may worth adding
> the rust/cargo error patterns to compile when using that mode
> 
> In my system so far I have this:
> 
> ```
> (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)))
> 
> ```
> 
> Maybe a more frequent rust user has a more general regex to
> recommend. But this one works for me.
> 
> WDYT?

Thanks, but could you please also send the examples of Rust messages,
because we need to add them to etc/compilation.txt?

bug#70794: 30.0.50; Add Rust compilation regex

[Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Sat, May 11, 2024 at 11:51:04AM GMT, Eli Zaretskii wrote:
>> Date: Mon, 06 May 2024 03:28:43 +0200
>> From:  Ergus via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> Recently working with rust I have noticed that emacs does not recognizes
>> the rust/cargo error patterns.
>>
>> Considering that emacs has now the rust-ts-mode, it may worth adding
>> the rust/cargo error patterns to compile when using that mode
>>
>> In my system so far I have this:
>>
>> ```
>> (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)))
>>
>> ```
>>
>> Maybe a more frequent rust user has a more general regex to
>> recommend. But this one works for me.
>>
>> WDYT?
>
>Thanks, but could you please also send the examples of Rust messages,
>because we need to add them to etc/compilation.txt?

Hi Eli:

Typically they look like this:

```
error[E0425]: cannot find function `ruun` in module `broot::cli`
   --> src/main.rs:6:23
    |
6  |     match broot::cli::ruun() {
    |                       ^^^^ help: a function with a similar name exists: `run`
    |
   ::: /tmp/broot/src/cli/mod.rs:49:1
    |
49 | pub fn run() -> Result<Option<Launchable>, ProgramError> {
    | -------------------------------------------------------- similarly
    named function `run` defined here
```

or

```
error: cannot find macro `deebug` in this scope
    --> src/main.rs:5:5
     |
5   |     deebug!("env::args(): {:#?}", std::env::args().collect::<Vec<String>>());
     |     ^^^^^^ help: a macro with a similar name exists: `debug`
     |
    ::: /home/ergo/.cargo/registry/src/index.crates.io-6f17d22bba15001f/log-0.4.21/src/macros.rs:154:1
     |
154 | macro_rules! debug {
     | ------------------ similarly named macro `debug` defined here
```

```
warning: crate-level attribute should be an inner attribute: add an exclamation mark: `#![foo]`
  --> src/main.rs:3:1
   |
3 | #[feature(proc_macro_diagnostic)]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: `#[warn(unused_attributes)]` on by default
```

Two details:

1. As you can see the [] is optional
2. The path is always relative to project's root

bug#70794: 30.0.50; Add Rust compilation regex

[Eli Zaretskii]

> Date: Wed, 15 May 2024 15:10:02 +0200
> From: Ergus <spacibba@aol.com>
> Cc: 70794@debbugs.gnu.org
> 
> On Sat, May 11, 2024 at 11:51:04AM GMT, Eli Zaretskii wrote:
> >
> >Thanks, but could you please also send the examples of Rust messages,
> >because we need to add them to etc/compilation.txt?
> 
> Hi Eli:
> 
> Typically they look like this:
> 
> ```
> error[E0425]: cannot find function `ruun` in module `broot::cli`
>    --> src/main.rs:6:23
>     |
> 6  |     match broot::cli::ruun() {
>     |                       ^^^^ help: a function with a similar name exists: `run`
>     |
>    ::: /tmp/broot/src/cli/mod.rs:49:1
>     |
> 49 | pub fn run() -> Result<Option<Launchable>, ProgramError> {
>     | -------------------------------------------------------- similarly
>     named function `run` defined here
> ```
> 
> or
> 
> ```
> error: cannot find macro `deebug` in this scope
>     --> src/main.rs:5:5
>      |
> 5   |     deebug!("env::args(): {:#?}", std::env::args().collect::<Vec<String>>());
>      |     ^^^^^^ help: a macro with a similar name exists: `debug`
>      |
>     ::: /home/ergo/.cargo/registry/src/index.crates.io-6f17d22bba15001f/log-0.4.21/src/macros.rs:154:1
>      |
> 154 | macro_rules! debug {
>      | ------------------ similarly named macro `debug` defined here
> ```
> 
> ```
> warning: crate-level attribute should be an inner attribute: add an exclamation mark: `#![foo]`
>   --> src/main.rs:3:1
>    |
> 3 | #[feature(proc_macro_diagnostic)]
>    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    |
>    = note: `#[warn(unused_attributes)]` on by default
> ```
> 
> Two details:
> 
> 1. As you can see the [] is optional
> 2. The path is always relative to project's root

Thanks, installed on master, and closing the bug.

bug#70794: 30.0.50; Add Rust compilation regex

[Mattias Engdegård]

Ergus, thank you for your contribution! Some questions, if you don't mind:

* There aren't any tests. If you care anything at all about your pattern working, and keep working, you should add some.

We'll help you out, of course, but it's probably best if you give it a go yourself first so that we know exactly what you want to match. Take a look at compile-tests.el, `compile-tests--test-regexps-data`. You will also need to increase the expected counts at the end of `compile-test-error-regexps`.

* The regexp doesn't match the variant with error code inside square brackets, the

error[E0425]: cannot find function `ruun` in module `broot::cli`

kind of message. Surely you intended it to?

Here is your regexp again, translated to rx and with line numbers for ease of discussion:

1 (rx (| (group-n 4 "error") (group-n 5 "warning"))
2     ":"
3     (+? (not (in "\x00")))
4     "--> "
5     (group-n 1 (+ (not (in ":"))))
6     ":"
7     (group-n 2 (+ digit))
8     ":"
9     (group-n 3 (+ digit)))

* (Line 1): From the examples it appears that the messages start at the beginning of a line. We very much prefer to anchor matches for reasons of performance and to avoid collisions with other patterns. How about we add a line-start anchor at the very beginning?

* (Line 3): This is an open-ended expression which will merrily match just about anything including newlines. This can become very expensive. And where does that NUL come from?

In the examples you supplied, the message is on the first line, and the " --> " on the start of the second. Can we rely on that? If not, what can we rely on?

* (Line 5): This excludes Windows file names which can include colon or do cargo messages have a special notation for those? In any case, it's usually a good idea to exclude newline as well to prevent a runaway repetition.

* Both the rust-mode and rustic packages appear to include regexps that match the same messages. How do they compare to yours?

What is the effect of someone using those modes with your regexp in Emacs?

bug#70794: 30.0.50; Add Rust compilation regex

[Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi Mattias:

Thanks for your interest on this. As I said in my first message I just
proposed what I have locally, but I didn't intent to insert the regex
there as it was.

On Fri, May 31, 2024 at 07:15:52PM GMT, Mattias Engdeg�rd wrote:
>Ergus, thank you for your contribution! Some questions, if you don't mind:
>
>* There aren't any tests. If you care anything at all about your pattern working, and keep working, you should add some.
>
>We'll help you out, of course, but it's probably best if you give it a go yourself first so that we know exactly what you want to match. Take a look at compile-tests.el, `compile-tests--test-regexps-data`. You will also need to increase the expected counts at the end of `compile-test-error-regexps`.
>
Actually Eli added this commit with the poor information I provided in
my mails because I don't have time to do it myself these days. Sorry for
not being more specific. I actually expected someone else more "rusty" to
provide more complete information (I actually does not use rust with
emacs very often)

>* The regexp doesn't match the variant with error code inside square brackets, the
>
>error[E0425]: cannot find function `ruun` in module `broot::cli`
>
>kind of message. Surely you intended it to?
>
You are right, Checking my local version I have a \\(\\[.+\\]\\)? before
the : in my pattern, not sure when I added that since my first mail.

>Here is your regexp again, translated to rx and with line numbers for
>ease of discussion:
I don't really understand the rx notatio :/ but I will try

>
>1 (rx (| (group-n 4 "error") (group-n 5 "warning"))
>2     ":"
>3     (+? (not (in "\x00")))
>4     "--> "
>5     (group-n 1 (+ (not (in ":"))))
>6     ":"
>7     (group-n 2 (+ digit))
>8     ":"
>9     (group-n 3 (+ digit)))
>

>* (Line 1): From the examples it appears that the messages start at the
>beginning of a line. We very much prefer to anchor matches for reasons
>of performance and to avoid collisions with other patterns. How about
>we add a line-start anchor at the very beginning?
>
It is ok. Probaly you may want to add also a line-end

>* (Line 3): This is an open-ended expression which will merrily match
>just about anything including newlines. This can become very
>expensive. And where does that NUL come from?
>
The NUL is actually negated to match anything up to the -->

>In the examples you supplied, the message is on the first line, and the " --> " on the start of the second. Can we rely on that? If not, what can we rely on?
>
I think yes; that's at least what I tried to match. If you have a
better/more efficient alternative fell free to change it.

>* (Line 5): This excludes Windows file names which can include colon or do cargo messages have a special notation for those? In any case, it's usually a good idea to exclude newline as well to prevent a runaway repetition.
>
In this case I think not, because the filename is always relative in
cargo and on MSWindows the colon comes after the drive in absolute paths
right? But I could be wrong.

>* Both the rust-mode and rustic packages appear to include regexps that match the same messages. How do they compare to yours?
>
You can take those indeed. I think they must be pretty much equivalent
and probably more complete because they probably match the "note:" case
which I preferred to ignore as emacs does not have an equivalent for
that.

IIRC they just don't use numeric capture groups, which I like a bit more
t avoid weird errors, but at the end the regex is pretty simple, any
alternative is fine.

>What is the effect of someone using those modes with your regexp in Emacs?
>
>
IIUC the packages pushes the entries in front of
compilation-error-regexp-alist-alist, so in principle their regexp will
match first and the loop stops.

So, the main changes you propose are something like:

"^\\(?:\\(?4:error\\)\\|\\(?5:warning\\)\\)\\(?:\\[.+\\]\\)?:[^\0]+?--> \\(?1:[^:]+\\):\\(?2:[[:digit:]]+\\):\\(?3:[[:digit:]]+\\)"

bug#70794: 30.0.50; Add Rust compilation regex

[Mattias Engdegård]

3 juni 2024 kl. 16.41 skrev Ergus <spacibba@aol.com>:

> I actually expected someone else more "rusty" to
> provide more complete information (I actually does not use rust with
> emacs very often)

Then maybe we should wait for someone with more Rust expertise to help out?
Without anyone actually using the stuff we risk making something that may not be useful or that is already unmaintained from the start with isn't a very good plan.
Or (as in this case) actually having a negative effect on the other patterns.

I really prefer we only add something when we know what we are doing.

bug#70794: 30.0.50; Add Rust compilation regex

[Mattias Engdegård]

There is also already a regexp that looks like it is used to match similar messages in `rust-ts-flymake`, but it lacks some of the problems listed above. Maybe they could be consolidated?

There is another problem with the added `cargo` regexp: its placement early in `compilation-error-regexp-alist-alist` causes it to match before other, possibly more frequently occurring patterns.
(That is not your (or Eli's) fault but an undocumented subtlety of that variable; I'll add a remark to the code.)

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. It seems we'll need to work harder on this one -- sorry.

bug#70794: 30.0.50; Add Rust compilation regex

[Eli Zaretskii]

> From: Mattias Engdegård <mattias.engdegard@gmail.com>
> Date: Mon, 3 Jun 2024 16:54:02 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  70794@debbugs.gnu.org
> 
> There is another problem with the added `cargo` regexp: its placement early in `compilation-error-regexp-alist-alist` causes it to match before other, possibly more frequently occurring patterns.
> (That is not your (or Eli's) fault but an undocumented subtlety of that variable; I'll add a remark to the code.)

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.

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

bug#70794: 30.0.50; Add Rust compilation regex

[Mattias Engdegård]

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.

bug#70794: 30.0.50; Add Rust compilation regex

[Eli Zaretskii]

> From: Mattias Engdegård <mattias.engdegard@gmail.com>
> Date: Mon, 3 Jun 2024 18:22:48 +0200
> Cc: spacibba@aol.com,
>  70794@debbugs.gnu.org
> 
> > 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.

Fine by me (I don't use Rust), but is the rule really broken?  What
happens if you move it to the end?

bug#70794: 30.0.50; Add Rust compilation regex

[Mattias Engdegård]

3 juni 2024 kl. 18.33 skrev Eli Zaretskii <eliz@gnu.org>:

> Fine by me (I don't use Rust), but is the rule really broken?  What
> happens if you move it to the end?

It is indeed broken as written because it would match anything starting with 'warning:' to something that looks like an arrow further down the log which could be an unrelated message a megabyte away.

I could try to slap together a guess at what a better one would be but then again, I wouldn't use it myself (rarely use Rust and when I do it's one of those external packages which have their own patterns and more importantly active maintainers). Furthermore I don't have the time to go poking around in the rustc (or cargo?) source code to see what the message-emitting parts look like, which is very useful when adding patterns.

Even with the obvious fixes, the pattern would still be incomplete and not even match parts of the examples given. I'm happy to work with Rust users or package maintainers to work out details but I don't want to do a rush job now, nor delay Emacs 30.

bug#70794: 30.0.50; Add Rust compilation regex

[Stefan Kangas]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> Even with the obvious fixes, the pattern would still be incomplete and not even match parts of the examples given. I'm happy to work with Rust users or package maintainers to work out details but I don't want to do a rush job now, nor delay Emacs 30.

BTW, shouldn't stuff like this be happier if it was in something like
`rust-mode`?

It seems like the maintainers of major modes are in a better position to
add and maintain support for the compilers and tools of their respective
languages than we are.

bug#70794: 30.0.50; Add Rust compilation regex

[Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Tue, Jun 04, 2024 at 06:06:16PM GMT, Stefan Kangas wrote:
>Mattias Engdeg�rd <mattias.engdegard@gmail.com> writes:
>
>> Even with the obvious fixes, the pattern would still be incomplete and not even match parts of the examples given. I'm happy to work with Rust users or package maintainers to work out details but I don't want to do a rush job now, nor delay Emacs 30.
>
>BTW, shouldn't stuff like this be happier if it was in something like
>`rust-mode`?
>
>It seems like the maintainers of major modes are in a better position to
>add and maintain support for the compilers and tools of their respective
>languages than we are.

Hi Stefan:

Actually I opened the initial issue because there is a rust-ts-mode now
in vanilla and in my opinion it is a bit incoherent to have a native
mode to support rust, but don't support compiling rust.

Specially considering that adding such support seems extremely simple,
it only requires to improve the regex to be a bit more strict. And the
one I provided is buggy mainly due to the "too free" wildcard I used to
match anything including the new line...

Just improving the [^\0]+?--> in the regex; I thing everything will work
properly.

bug#70794: 30.0.50; Add Rust compilation regex

[Stefan Kangas]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 3 juni 2024 kl. 18.33 skrev Eli Zaretskii <eliz@gnu.org>:
>
>> Fine by me (I don't use Rust), but is the rule really broken?  What
>> happens if you move it to the end?
>
> It is indeed broken as written because it would match anything
> starting with 'warning:' to something that looks like an arrow further
> down the log which could be an unrelated message a megabyte away.
>
> I could try to slap together a guess at what a better one would be but
> then again, I wouldn't use it myself (rarely use Rust and when I do
> it's one of those external packages which have their own patterns and
> more importantly active maintainers). Furthermore I don't have the
> time to go poking around in the rustc (or cargo?) source code to see
> what the message-emitting parts look like, which is very useful when
> adding patterns.
>
> Even with the obvious fixes, the pattern would still be incomplete and
> not even match parts of the examples given. I'm happy to work with
> Rust users or package maintainers to work out details but I don't want
> to do a rush job now, nor delay Emacs 30.

Randy, would you be interested in working with Mattias to create a good
`compilation-mode` regexp for Rust?

bug#70794: 30.0.50; Add Rust compilation regex

[Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Mon, Jun 03, 2024 at 06:22:48PM GMT, Mattias Engdeg�rd wrote:
>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.
>
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.
>

bug#70794: 30.0.50; Add Rust compilation regex

[Eli Zaretskii]

> Date: Tue, 4 Jun 2024 00:36:17 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 70794@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@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).

bug#70794: 30.0.50; Add Rust compilation regex

[Eli Zaretskii]

> From: Mattias Engdegård <mattias.engdegard@gmail.com>
> Date: Mon, 3 Jun 2024 16:54:02 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  70794@debbugs.gnu.org
> 
> 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. It seems we'll need to work harder on this one -- sorry.

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.

Thanks.