On Fri, Sep 23, 2022 at 6:10 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Do you have a test case that demonstrates the problem?

Yes, so what I initially wanted to do was parse dialyzer errors
when running using the rebar3 package manager with `rebar3 dialyzer`.
See attachment for example output.

This is what I ended up with

    (setq compilation-error-regexp-alist
          (cons
           '("^\\(?:\n\\(.*\\)\n\\)?Line \\([0-9]+\\)\\(?: Column
\\([0-9]+\\)\\)?: " 1 2 3 1)
           (cons
            ;; This next error regexp should not be necessary
according to documentation.
            '("^Line \\([0-9]+\\)\\(?: Column \\([0-9]+\\)\\)?: " nil 1 2 1)
            (eval (car (get 'compilation-error-regexp-alist
'standard-value))))))

only with the 2nd error regexp does all errors get parsed.
Though this is unexpected: In the 1st regexp
when the first subexpression containing the file name does not match,
the docs say it should act the same as the 2nd error regexp.

When I have `eval-defun`:ed the patched version of
`compilation-error-properties`,
the 1st error regexp suffices as expected.

> I think this change might be too large to apply without having an FSF
> copyright assignment on file -- would you be willing to sign such
> paperwork?

The patch is mostly all indentation changes,
but yes, if needed I would be willing
though I would have to consult with my employer first.