Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour

From: "Paul D. Nelson" <[email-masked]>
Date: Sun, 20 Apr 2025 18:04:27 +0200

Eli Zaretskii <[email-masked]> writes:

>> The erroneous property gets added in compilation-parse-errors in the
>> final "add-text-properties", apparently because the regexp used to
>> detect matches picks up the "Grep finished..." line.
>
> Thanks, but can you be more specific?  Which regexp is that, and why
> does it match "Grep finished..." only sometimes?

Sure.  It's the first regexp from grep-regexp-alist, and it matches
"Grep finished..." consistently: evaluating

(with-temp-buffer
  (insert "./test.txt:1:foo

Grep finished with matches found at Sun Apr 20 15:28:29, duration 0.10 s")
  (let ((pat (car (nth 0 grep-regexp-alist)))
        results)
    (goto-char (point-min))
    (while (re-search-forward pat nil t)
      (push 
       (list :file (match-string 1) :line (match-string 2))
       results))
    (nreverse results)))

yields

((:file "./test.txt" :line "1")
 (:file "Grep finished with matches found at Sun Apr 20 15" :line "28"))

As a result, compilation-parse-errors adds the compilation-message
property to "Grep finished".

Thus, with font-lock disabled, there's a clear, reproducible bug caused
by a broad regexp.

When font-lock is enabled, it often "covers up" the bug via the
following entry in grep-mode-font-lock-keywords (simplified):

("^Grep[/a-zA-Z]* finished with \\(...\\).*"
  (0 '(face nil compilation-message nil ...) t) ...)

The unpredictability must come from some race between
compilation-parse-errors and font-lock-fontify-region.  I think the
right thing to do is to fix the bug in the "font lock disabled" case,
but it's a complicated issue and I don't have an immediate suggestion.