GNU bug report logs - #77732
grep-edit-buffer errors with incionsistent behaviour

Previous Next

Package: emacs;

Reported by: Johann Höchtl <johann.hoechtl <at> gmail.com>

Date: Fri, 11 Apr 2025 09:35:02 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: johann.hoechtl <at> gmail.com, 77732 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Sun, 20 Apr 2025 18:04:27 +0200
Eli Zaretskii <eliz <at> gnu.org> 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.




This bug report was last modified 23 days ago.

Previous Next


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