GNU bug report logs -
#77732
grep-edit-buffer errors with incionsistent behaviour
Previous Next
Full log
View this message in rfc822 format
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.