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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77732 in the body.
You can then email your comments to 77732 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Johann Höchtl <johann.hoechtl <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: grep-edit-buffer errors with incionsistent behaviour
Date: Fri, 11 Apr 2025 11:33:59 +0200

[Message part 1 (text/plain, inline)]

I am using Emacs from HEAD on Windows

I tried to reproduce the behaviour with emacs -Q but it still remains
inconsistent.

When I rgrep and there are few results (< 15) , I can enter grep buffer
pres 'e' to enter grep-edit mode, get out of it with C-c C-c, re-enter with
'e' and so on.

When there are more results, (between 15 and 70)  I still can enter with
'e' get out with C-c C-c but when I try to re-enter I get the error message
Wrong type argument: stringp, nil
The buffer later although still in grp-mode does not behave any longer as a
grep mode, 'g' or 'e' results in the error Buffer is read only : #<buffer
*grep*>

When there are many results, I get the error message Wrong type argument:
stringp, nil already on the first invocation attempt.

Thew boundaries are somewhat moving but at least I have the feeling the
more matches are, the more frequently I run into the

Wrong type argument: stringp, nil

already at first try.

[Message part 2 (text/html, inline)]

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

From: Visuwesh <visuweshm <at> gmail.com>
To: Johann Höchtl <johann.hoechtl <at> gmail.com>
Cc: 77732 <at> debbugs.gnu.org
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Fri, 11 Apr 2025 16:07:54 +0530

[வெள்ளி ஏப்ரல் 11, 2025] Johann Höchtl wrote:

> I am using Emacs from HEAD on Windows
>
> I tried to reproduce the behaviour with emacs -Q but it still remains
> inconsistent.
>
> When I rgrep and there are few results (< 15) , I can enter grep buffer
> pres 'e' to enter grep-edit mode, get out of it with C-c C-c, re-enter with
> 'e' and so on.
>
> When there are more results, (between 15 and 70)  I still can enter with
> 'e' get out with C-c C-c but when I try to re-enter I get the error message
> Wrong type argument: stringp, nil
> The buffer later although still in grp-mode does not behave any longer as a
> grep mode, 'g' or 'e' results in the error Buffer is read only : #<buffer
> *grep*>
>
> When there are many results, I get the error message Wrong type argument:
> stringp, nil already on the first invocation attempt.
>
> Thew boundaries are somewhat moving but at least I have the feeling the
> more matches are, the more frequently I run into the
>
> Wrong type argument: stringp, nil
>
> already at first try.

Can you please share the backtrace?  Say M-x toggle-debug-on-error RET
before trying to reproduce the error above.  I mostly tested
grep-edit-mode with M-x rgrep, and a good amount of results.

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

From: Visuwesh <visuweshm <at> gmail.com>
To: Johann Höchtl <johann.hoechtl <at> gmail.com>
Cc: 77732 <at> debbugs.gnu.org
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Fri, 11 Apr 2025 17:21:40 +0530

[ Please use Reply All in your mail client to ensure the entire
  conversation is recorded in the bug tracker.  ]

[வெள்ளி ஏப்ரல் 11, 2025] Johann Höchtl wrote:

> First thank you for the hint of toggle-debug-on-error, TIL
>
> The trace:
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   compilation-find-file-1(#<marker in no buffer> "Grep started at Fri Apr
> 11 12" nil nil)
>   compilation-find-file(#<marker in no buffer> "Grep started at Fri Apr 11
> 12" nil)
>   compilation--update-markers((nil 58 (("Grep started at Fri Apr 11 12"
> nil) nil (58 #1)) nil nil) #<marker in no buffer> nil 0)
>   grep-edit--prepare-buffer()
>   grep-change-to-grep-edit-mode()
>   funcall-interactively(grep-change-to-grep-edit-mode)
>   command-execute(grep-change-to-grep-edit-mode)
>
>
> The buffer starts the following:
>
> -*- mode: grep; default-directory: "~/OneDrive - Online/Dokumente/" -*-
> Grep started at Fri Apr 11 12:58:57
>

I can reproduce the issue with 17 hits but not with >200.  I will try
digging into this more.

> Am Fr., 11. Apr. 2025 um 12:37 Uhr schrieb Visuwesh <visuweshm <at> gmail.com>:
>
>> [வெள்ளி ஏப்ரல் 11, 2025] Johann Höchtl wrote:
>>
>> > I am using Emacs from HEAD on Windows
>> >
>> > I tried to reproduce the behaviour with emacs -Q but it still remains
>> > inconsistent.
>> >
>> > When I rgrep and there are few results (< 15) , I can enter grep buffer
>> > pres 'e' to enter grep-edit mode, get out of it with C-c C-c, re-enter
>> with
>> > 'e' and so on.
>> >
>> > When there are more results, (between 15 and 70)  I still can enter with
>> > 'e' get out with C-c C-c but when I try to re-enter I get the error
>> message
>> > Wrong type argument: stringp, nil
>> > The buffer later although still in grp-mode does not behave any longer
>> as a
>> > grep mode, 'g' or 'e' results in the error Buffer is read only : #<buffer
>> > *grep*>
>> >
>> > When there are many results, I get the error message Wrong type argument:
>> > stringp, nil already on the first invocation attempt.
>> >
>> > Thew boundaries are somewhat moving but at least I have the feeling the
>> > more matches are, the more frequently I run into the
>> >
>> > Wrong type argument: stringp, nil
>> >
>> > already at first try.
>>
>> Can you please share the backtrace?  Say M-x toggle-debug-on-error RET
>> before trying to reproduce the error above.  I mostly tested
>> grep-edit-mode with M-x rgrep, and a good amount of results.
>>

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Johann Höchtl <johann.hoechtl <at> gmail.com>
Cc: 77732 <at> debbugs.gnu.org
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Fri, 11 Apr 2025 14:57:42 +0300

> From: Johann Höchtl <johann.hoechtl <at> gmail.com>
> Date: Fri, 11 Apr 2025 11:33:59 +0200
> 
> I am using Emacs from HEAD on Windows
> 
> I tried to reproduce the behaviour with emacs -Q but it still remains inconsistent.
> 
> When I rgrep and there are few results (< 15) , I can enter grep buffer pres 'e' to enter grep-edit mode, get
> out of it with C-c C-c, re-enter with 'e' and so on.
> 
> When there are more results, (between 15 and 70)  I still can enter with 'e' get out with C-c C-c but when I try
> to re-enter I get the error message Wrong type argument: stringp, nil
> The buffer later although still in grp-mode does not behave any longer as a grep mode, 'g' or 'e' results in the
> error Buffer is read only : #<buffer *grep*>
> 
> When there are many results, I get the error message Wrong type argument: stringp, nil already on the first
> invocation attempt.

I cannot reproduce this with today's master branch on MS-Windows.  I
just tried with a Grep command that yielded 128 hits, and didn't see
any errors.

Please show the complete recipe for reproducing the problem, with all
the steps and commands explicitly shown.  It is best if you can show
this in the Emacs source tree, so that all of us can easily try the
same recipe with the same files.

Thanks.

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

From: Visuwesh <visuweshm <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Johann Höchtl <johann.hoechtl <at> gmail.com>,
 77732 <at> debbugs.gnu.org
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Fri, 11 Apr 2025 18:01:27 +0530

[Message part 1 (text/plain, inline)]

[வெள்ளி ஏப்ரல் 11, 2025] Eli Zaretskii wrote:

>> From: Johann Höchtl <johann.hoechtl <at> gmail.com>
>> Date: Fri, 11 Apr 2025 11:33:59 +0200
>> 
>> I am using Emacs from HEAD on Windows
>> 
>> I tried to reproduce the behaviour with emacs -Q but it still remains inconsistent.
>> 
>> When I rgrep and there are few results (< 15) , I can enter grep buffer pres 'e' to enter grep-edit mode, get
>> out of it with C-c C-c, re-enter with 'e' and so on.
>> 
>> When there are more results, (between 15 and 70)  I still can enter with 'e' get out with C-c C-c but when I try
>> to re-enter I get the error message Wrong type argument: stringp, nil
>> The buffer later although still in grp-mode does not behave any longer as a grep mode, 'g' or 'e' results in the
>> error Buffer is read only : #<buffer *grep*>
>> 
>> When there are many results, I get the error message Wrong type argument: stringp, nil already on the first
>> invocation attempt.
>
> I cannot reproduce this with today's master branch on MS-Windows.  I
> just tried with a Grep command that yielded 128 hits, and didn't see
> any errors.

It seems like the number of hits is specific for this bug to hit.

> Please show the complete recipe for reproducing the problem, with all
> the steps and commands explicitly shown.  It is best if you can show
> this in the Emacs source tree, so that all of us can easily try the
> same recipe with the same files.

Here's a reproduction:

  1. Download the attachment cp2k-mode.el
  2. emacs -Q
  3. M-x grep RET
  4. After '-e' in the command, type " '^(def[^ ]\+ cp2k-' cp2k-mode.el".
  5. The above grep command should produce 17 hits.
  6. Say e.
  7. Say C-c C-c.
  8. Say e.
  9. After this, move your point to "Grep finished..." message, and
     inspect the value of the text-property compilation-message.  It
     should have a non-nil value.
  10. Say C-c.
  11. Say e, and witness the reported error.

I inserted a few message statements (see patch below), and I cannot
figure out where the sudden addition in the compilation-message is
coming from.  We could bail from calling grep-edit--prepare-buffer if we
detect an occur-target-prefix text-property but there might be a deeper
seated bug somewhere.

diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el
index b0105f08ea2..ec2b600971c 100644
--- a/lisp/progmodes/grep.el
+++ b/lisp/progmodes/grep.el
@@ -1055,15 +1055,18 @@ grep
 (defun grep-edit--prepare-buffer ()
   "Mark relevant regions read-only, and add relevant occur text-properties."
   (save-excursion
+    (message "----")
     (goto-char (point-min))
     (let ((inhibit-read-only t)
           (dummy (make-marker))
           match)
-      (while (setq match (text-property-search-forward 'compilation-annotation))
+      (while (setq match (text-property-search-forward 'compilation-annotation
+                                                       nil (lambda (_val prop-val) prop-val)))
         (add-text-properties (prop-match-beginning match) (prop-match-end match)
                              '(read-only t)))
       (goto-char (point-min))
       (while (setq match (text-property-search-forward 'compilation-message))
+        (message "%S %S" (point) (get-text-property 2527 'compilation-message))
         (add-text-properties (prop-match-beginning match) (prop-match-end match)
                              '(read-only t occur-prefix t))
         (let ((loc (compilation--message->loc (prop-match-value match)))
@@ -1078,7 +1081,8 @@ grep-edit--prepare-buffer
                                     (prop-match-end match)
                                     'compilation-message)
                                    (1+ (pos-eol)))
-                               `(occur-target ((,m . ,m)))))))))
+                               `(occur-target ((,m . ,m))))))
+      (message "%S %S" (point) (get-text-property 2527 'compilation-message)))))
 
 (defvar-keymap grep-edit-mode-map
   :doc "Keymap for `grep-edit-mode'."
@@ -1109,21 +1113,26 @@ grep-change-to-grep-edit-mode
   (when (get-buffer-process (current-buffer))
     (error "Cannot switch when grep is running"))
   (use-local-map grep-edit-mode-map)
+  (message "before prep %S %S" (point) (get-text-property 2527 'compilation-message))
   (grep-edit--prepare-buffer)
+  (message "after prep %S %S" (point) (get-text-property 2527 'compilation-message))
   (setq buffer-read-only nil)
   (setq major-mode 'grep-edit-mode)
   (setq mode-name "Grep-Edit")
   (buffer-enable-undo)
+  (message "after undo %S %S" (point) (get-text-property 2527 'compilation-message))
   (set-buffer-modified-p nil)
   (setq buffer-undo-list nil)
   (add-hook 'after-change-functions #'occur-after-change-function nil t)
   (run-mode-hooks 'grep-edit-mode-hook)
+  (message "after hook %S %S" (point) (get-text-property 2527 'compilation-message))
   (message (substitute-command-keys
             "Editing: Type \\[grep-edit-save-changes] to return to Grep mode")))
 
 (defun grep-edit-save-changes ()
   "Switch back to Grep mode."
   (interactive)
+  (message "%S %S" (point) (get-text-property 2527 'compilation-message))
   (unless (derived-mode-p 'grep-edit-mode)
     (error "Not a Grep-Edit buffer"))
   (remove-hook 'after-change-functions #'occur-after-change-function t)
@@ -1134,7 +1143,8 @@ grep-edit-save-changes
   (force-mode-line-update)
   (buffer-disable-undo)
   (setq buffer-undo-list t)
-  (message "Switching to Grep mode"))
+  (message "Switching to Grep mode")
+  (message "%S %S" (point) (get-text-property 2527 'compilation-message)))
 
 ;;;###autoload
 (defun grep-find (command-args)

[cp2k-mode.el (application/emacs-lisp, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: johann.hoechtl <at> gmail.com, 77732 <at> debbugs.gnu.org
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Fri, 11 Apr 2025 18:56:37 +0300

> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: Johann Höchtl <johann.hoechtl <at> gmail.com>,
>   77732 <at> debbugs.gnu.org
> Date: Fri, 11 Apr 2025 18:01:27 +0530
> 
> I inserted a few message statements (see patch below), and I cannot
> figure out where the sudden addition in the compilation-message is
> coming from.

Which addition is that?  I'm afraid you lost me here.

Can you explain which line of code causes the error, and why?

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

From: Visuwesh <visuweshm <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: johann.hoechtl <at> gmail.com, 77732 <at> debbugs.gnu.org
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Fri, 11 Apr 2025 21:42:51 +0530

[வெள்ளி ஏப்ரல் 11, 2025] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: Johann Höchtl <johann.hoechtl <at> gmail.com>,
>>   77732 <at> debbugs.gnu.org
>> Date: Fri, 11 Apr 2025 18:01:27 +0530
>> 
>> I inserted a few message statements (see patch below), and I cannot
>> figure out where the sudden addition in the compilation-message is
>> coming from.
>
> Which addition is that?  I'm afraid you lost me here.

Oops, I butchered the statement: after the second time you type 'e', the
"Grep finished..." message attains a non-nil compilation-message
text-property.

> Can you explain which line of code causes the error, and why?

That's what I tried to figure out by adding the message statements but I
fail to understand how the compilation-message text-property is being
Added.  The relevant bits from *Messages* is at the end.

When I say 'e' for the first time then go back to grep-mode with C-c
C-c, there's no extra compilation-message text-property.

When I say 'e' for the second time around, till the end of
grep-change-to-grep-edit-mode, there's no extra compilation-message
text-property (lines marked with *).  But in the gap between
grep-change-to-grep-edit-mode and me saying C-c C-c (with no other
action being done by me in between), the extra compilation-message
text-property is added to the "Grep finished..." line.

    Grep finished with 17 matches found
    before prep 1 nil
    ----
    1666 nil
    1718 nil
    1769 nil
    1809 nil
    1847 nil
    1890 nil
    1932 nil
    1974 nil
    2024 nil
    2074 nil
    2149 nil
    2218 nil
    2269 nil
    2321 nil
    2378 nil
    2424 nil
    2471 nil [2 times]
    after prep 1 nil
    after undo 1 nil
    after hook 1 nil
    Editing: Type C-c C-c to return to Grep mode
    1 nil
    Switching to Grep mode
    1 nil
    before prep 1 nil
    ----
    1666 nil
    1718 nil
    1769 nil
    1809 nil
    1847 nil
    1890 nil
    1932 nil
    1974 nil
    2024 nil
    2074 nil
    2149 nil
    2218 nil
    2269 nil
    2321 nil
    2378 nil
    2424 nil
    2471 nil [2 times]
*   after prep 1 nil
*   after undo 1 nil
*   after hook 1 nil
    Editing: Type C-c C-c to return to Grep mode
    1 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    Switching to Grep mode
    1 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    before prep 1 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    ----
    1666 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    1718 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    1769 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    1809 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    1847 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    1890 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    1932 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    1974 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    2024 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    2074 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    2149 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    2218 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    2269 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    2321 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    2378 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    2424 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    2471 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    2583 #s(compilation--message (nil 33 (("Grep finished with 17 matches found at Fri Apr 11 21" nil) nil (33 #1)) nil nil) 2 nil nil)
    Entering debugger...

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: johann.hoechtl <at> gmail.com, 77732 <at> debbugs.gnu.org
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Sat, 12 Apr 2025 13:26:14 +0300

> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: johann.hoechtl <at> gmail.com,  77732 <at> debbugs.gnu.org
> Date: Fri, 11 Apr 2025 21:42:51 +0530
> 
> [வெள்ளி ஏப்ரல் 11, 2025] Eli Zaretskii wrote:
> 
> >> From: Visuwesh <visuweshm <at> gmail.com>
> >> Cc: Johann Höchtl <johann.hoechtl <at> gmail.com>,
> >>   77732 <at> debbugs.gnu.org
> >> Date: Fri, 11 Apr 2025 18:01:27 +0530
> >> 
> >> I inserted a few message statements (see patch below), and I cannot
> >> figure out where the sudden addition in the compilation-message is
> >> coming from.
> >
> > Which addition is that?  I'm afraid you lost me here.
> 
> Oops, I butchered the statement: after the second time you type 'e', the
> "Grep finished..." message attains a non-nil compilation-message
> text-property.
> 
> > Can you explain which line of code causes the error, and why?
> 
> That's what I tried to figure out by adding the message statements but I
> fail to understand how the compilation-message text-property is being
> Added.  The relevant bits from *Messages* is at the end.
> 
> When I say 'e' for the first time then go back to grep-mode with C-c
> C-c, there's no extra compilation-message text-property.
> 
> When I say 'e' for the second time around, till the end of
> grep-change-to-grep-edit-mode, there's no extra compilation-message
> text-property (lines marked with *).  But in the gap between
> grep-change-to-grep-edit-mode and me saying C-c C-c (with no other
> action being done by me in between), the extra compilation-message
> text-property is added to the "Grep finished..." line.

I'm guessing this is font-lock (called via jit-lock mechanism)?

Maybe you should do something with font-lock-extra-managed-props?

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

From: Visuwesh <visuweshm <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: johann.hoechtl <at> gmail.com, 77732 <at> debbugs.gnu.org
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Sat, 12 Apr 2025 17:40:07 +0530

[சனி ஏப்ரல் 12, 2025] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: johann.hoechtl <at> gmail.com,  77732 <at> debbugs.gnu.org
>> Date: Fri, 11 Apr 2025 21:42:51 +0530
>> 
>> [வெள்ளி ஏப்ரல் 11, 2025] Eli Zaretskii wrote:
>> 
>> >> From: Visuwesh <visuweshm <at> gmail.com>
>> >> Cc: Johann Höchtl <johann.hoechtl <at> gmail.com>,
>> >>   77732 <at> debbugs.gnu.org
>> >> Date: Fri, 11 Apr 2025 18:01:27 +0530
>> >> 
>> >> I inserted a few message statements (see patch below), and I cannot
>> >> figure out where the sudden addition in the compilation-message is
>> >> coming from.
>> >
>> > Which addition is that?  I'm afraid you lost me here.
>> 
>> Oops, I butchered the statement: after the second time you type 'e', the
>> "Grep finished..." message attains a non-nil compilation-message
>> text-property.
>> 
>> > Can you explain which line of code causes the error, and why?
>> 
>> That's what I tried to figure out by adding the message statements but I
>> fail to understand how the compilation-message text-property is being
>> Added.  The relevant bits from *Messages* is at the end.
>> 
>> When I say 'e' for the first time then go back to grep-mode with C-c
>> C-c, there's no extra compilation-message text-property.
>> 
>> When I say 'e' for the second time around, till the end of
>> grep-change-to-grep-edit-mode, there's no extra compilation-message
>> text-property (lines marked with *).  But in the gap between
>> grep-change-to-grep-edit-mode and me saying C-c C-c (with no other
>> action being done by me in between), the extra compilation-message
>> text-property is added to the "Grep finished..." line.
>
> I'm guessing this is font-lock (called via jit-lock mechanism)?

That may be the case...

> Maybe you should do something with font-lock-extra-managed-props?

Just pushing 'compilation-message to font-lock-extra-managed-props did
not help.  Unfortunately, I do not know enough to debug this one.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: johann.hoechtl <at> gmail.com, 77732 <at> debbugs.gnu.org
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Sat, 12 Apr 2025 15:51:36 +0300

> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: johann.hoechtl <at> gmail.com,  77732 <at> debbugs.gnu.org
> Date: Sat, 12 Apr 2025 17:40:07 +0530
> 
> [சனி ஏப்ரல் 12, 2025] Eli Zaretskii wrote:
> 
> >> From: Visuwesh <visuweshm <at> gmail.com>
> >> Cc: johann.hoechtl <at> gmail.com,  77732 <at> debbugs.gnu.org
> >> Date: Fri, 11 Apr 2025 21:42:51 +0530
> >> 
> >> [வெள்ளி ஏப்ரல் 11, 2025] Eli Zaretskii wrote:
> >> 
> >> >> From: Visuwesh <visuweshm <at> gmail.com>
> >> >> Cc: Johann Höchtl <johann.hoechtl <at> gmail.com>,
> >> >>   77732 <at> debbugs.gnu.org
> >> >> Date: Fri, 11 Apr 2025 18:01:27 +0530
> >> >> 
> >> >> I inserted a few message statements (see patch below), and I cannot
> >> >> figure out where the sudden addition in the compilation-message is
> >> >> coming from.
> >> >
> >> > Which addition is that?  I'm afraid you lost me here.
> >> 
> >> Oops, I butchered the statement: after the second time you type 'e', the
> >> "Grep finished..." message attains a non-nil compilation-message
> >> text-property.
> >> 
> >> > Can you explain which line of code causes the error, and why?
> >> 
> >> That's what I tried to figure out by adding the message statements but I
> >> fail to understand how the compilation-message text-property is being
> >> Added.  The relevant bits from *Messages* is at the end.
> >> 
> >> When I say 'e' for the first time then go back to grep-mode with C-c
> >> C-c, there's no extra compilation-message text-property.
> >> 
> >> When I say 'e' for the second time around, till the end of
> >> grep-change-to-grep-edit-mode, there's no extra compilation-message
> >> text-property (lines marked with *).  But in the gap between
> >> grep-change-to-grep-edit-mode and me saying C-c C-c (with no other
> >> action being done by me in between), the extra compilation-message
> >> text-property is added to the "Grep finished..." line.
> >
> > I'm guessing this is font-lock (called via jit-lock mechanism)?
> 
> That may be the case...
> 
> > Maybe you should do something with font-lock-extra-managed-props?
> 
> Just pushing 'compilation-message to font-lock-extra-managed-props did
> not help.  Unfortunately, I do not know enough to debug this one.

And it doesn't help that it is a heisenbug: I could only reproduce it
once, even with your recipe.

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

From: Visuwesh <visuweshm <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: johann.hoechtl <at> gmail.com, 77732 <at> debbugs.gnu.org
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Sat, 12 Apr 2025 20:23:45 +0530

[சனி ஏப்ரல் 12, 2025] Eli Zaretskii wrote:

> [...]
>> >> When I say 'e' for the second time around, till the end of
>> >> grep-change-to-grep-edit-mode, there's no extra compilation-message
>> >> text-property (lines marked with *).  But in the gap between
>> >> grep-change-to-grep-edit-mode and me saying C-c C-c (with no other
>> >> action being done by me in between), the extra compilation-message
>> >> text-property is added to the "Grep finished..." line.
>> >
>> > I'm guessing this is font-lock (called via jit-lock mechanism)?
>> 
>> That may be the case...
>> 
>> > Maybe you should do something with font-lock-extra-managed-props?
>> 
>> Just pushing 'compilation-message to font-lock-extra-managed-props did
>> not help.  Unfortunately, I do not know enough to debug this one.
>
> And it doesn't help that it is a heisenbug: I could only reproduce it
> once, even with your recipe.

I can reproduce it every time I repeat the recipe.  Does it help to use
M-x rgrep instead?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: johann.hoechtl <at> gmail.com, 77732 <at> debbugs.gnu.org
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Sun, 13 Apr 2025 09:03:56 +0300

> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: johann.hoechtl <at> gmail.com,  77732 <at> debbugs.gnu.org
> Date: Sat, 12 Apr 2025 20:23:45 +0530
> 
> [சனி ஏப்ரல் 12, 2025] Eli Zaretskii wrote:
> 
> > [...]
> >> >> When I say 'e' for the second time around, till the end of
> >> >> grep-change-to-grep-edit-mode, there's no extra compilation-message
> >> >> text-property (lines marked with *).  But in the gap between
> >> >> grep-change-to-grep-edit-mode and me saying C-c C-c (with no other
> >> >> action being done by me in between), the extra compilation-message
> >> >> text-property is added to the "Grep finished..." line.
> >> >
> >> > I'm guessing this is font-lock (called via jit-lock mechanism)?
> >> 
> >> That may be the case...
> >> 
> >> > Maybe you should do something with font-lock-extra-managed-props?
> >> 
> >> Just pushing 'compilation-message to font-lock-extra-managed-props did
> >> not help.  Unfortunately, I do not know enough to debug this one.
> >
> > And it doesn't help that it is a heisenbug: I could only reproduce it
> > once, even with your recipe.
> 
> I can reproduce it every time I repeat the recipe.  Does it help to use
> M-x rgrep instead?

No.

Message #41 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, 13 Apr 2025 10:01:25 +0200

Here's a reliable recipe that produces what I suspect is the key issue:

----------------------------------------
emacs -Q

Disable global-font-lock-mode.

Use rgrep in any situation that returns some match.  (The emacs source
tree works, as does a dummy folder containing "test.txt" with a single
line "foo".)

In the *grep* buffer, press n.
----------------------------------------

After this, the line "Grep finished ..." has the compilation-message
text property, which should not happen.

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.

Hope this helps narrow it down.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
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: Sat, 19 Apr 2025 17:18:10 +0300

> From: "Paul D. Nelson" <ultrono <at> gmail.com>
> Cc: visuweshm <at> gmail.com, johann.hoechtl <at> gmail.com, 77732 <at> debbugs.gnu.org
> Date: Sun, 13 Apr 2025 10:01:25 +0200
> 
> Here's a reliable recipe that produces what I suspect is the key issue:
> 
> ----------------------------------------
> emacs -Q
> 
> Disable global-font-lock-mode.
> 
> Use rgrep in any situation that returns some match.  (The emacs source
> tree works, as does a dummy folder containing "test.txt" with a single
> line "foo".)
> 
> In the *grep* buffer, press n.
> ----------------------------------------
> 
> After this, the line "Grep finished ..." has the compilation-message
> text property, which should not happen.
> 
> 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?

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.

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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: johann.hoechtl <at> gmail.com, eliz <at> gnu.org, 77732 <at> debbugs.gnu.org,
 visuweshm <at> gmail.com
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Mon, 21 Apr 2025 16:27:09 +0200

[Message part 1 (text/plain, inline)]

I took a look at the manual entry for compilation-mode, which contains:

       Sometimes ‘compilation-error-regexp-alist’ doesn't correctly
    determine the filename that is the source of the error.  Use user option
    ‘compilation-transform-file-match-alist’ to make any necessary
    adjustments, such as adding or changing a directory component, or even
    considering certain compiler messages not error messages at all.

This suggests a surgical fix (attached) that addresses the cases of the
bug that I had been able to reproduce.  Perhaps Johann can check if it
addresses his cases, too.

[0001-Fix-grep-buffer-display-of-finished-lines-as-matches.patch (text/x-patch, attachment)]

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

From: Johann Höchtl <johann.hoechtl <at> gmail.com>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: eliz <at> gnu.org, 77732 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Tue, 22 Apr 2025 17:11:49 +0200

[Message part 1 (text/plain, inline)]

I extracted grep.el from grep.el.gz
I loaded the patch and applied it to grep.el
The hunks applied successfully

I retried my rgrep opperation and got this in messages:

Source file
‘c:/Users/HoechtlJ/AppData/Local/Emacs/share/emacs/31.0.50/lisp/progmodes/grep.el’
newer than byte-compiled file; using older file
Making completion list...
compilation-start: Symbol’s value as variable is void:
grep-compilation-transform-finished-rules [2 times]

So I renamed grep.el.gz to grep.elgz.o and grep.elc to grep.elc.o

Still no luck but the compilation error remains compilation-start: Symbol’s
value as variable is void: grep-compilation-transform-finished-rules

A new native byte compiled version of grep.el was created though.

Is the compilation error actually misleading? It seems as if I get the error

Source file
‘c:/Users/HoechtlJ/AppData/Local/Emacs/share/emacs/31.0.50/lisp/progmodes/grep.el’
newer than byte-compiled file; using older file
Making completion list...
compilation-start: Symbol’s value as variable is void:
grep-compilation-transform-finished-rule

using older file would indicate that it is using grep.elc but it seems
Emacs does in fact use the NEW pathed grep.el

Am Mo., 21. Apr. 2025 um 16:27 Uhr schrieb Paul D. Nelson <ultrono <at> gmail.com
>:

> I took a look at the manual entry for compilation-mode, which contains:
>
>        Sometimes ‘compilation-error-regexp-alist’ doesn't correctly
>     determine the filename that is the source of the error.  Use user
> option
>     ‘compilation-transform-file-match-alist’ to make any necessary
>     adjustments, such as adding or changing a directory component, or even
>     considering certain compiler messages not error messages at all.
>
> This suggests a surgical fix (attached) that addresses the cases of the
> bug that I had been able to reproduce.  Perhaps Johann can check if it
> addresses his cases, too.
>
>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Johann Höchtl <johann.hoechtl <at> gmail.com>
Cc: visuweshm <at> gmail.com, 77732 <at> debbugs.gnu.org, ultrono <at> gmail.com
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Tue, 22 Apr 2025 18:30:00 +0300

> From: Johann Höchtl <johann.hoechtl <at> gmail.com>
> Date: Tue, 22 Apr 2025 17:11:49 +0200
> Cc: eliz <at> gnu.org, visuweshm <at> gmail.com, 77732 <at> debbugs.gnu.org
> 
> I extracted grep.el from grep.el.gz
> I loaded the patch and applied it to grep.el
> The hunks applied successfully
> 
> I retried my rgrep opperation and got this in messages:
> 
> Source file ‘c:/Users/HoechtlJ/AppData/Local/Emacs/share/emacs/31.0.50/lisp/progmodes/grep.el’ newer
> than byte-compiled file; using older file
> Making completion list...
> compilation-start: Symbol’s value as variable is void: grep-compilation-transform-finished-rules [2 times]
> 
> So I renamed grep.el.gz to grep.elgz.o and grep.elc to grep.elc.o
> 
> Still no luck but the compilation error remains compilation-start: Symbol’s value as variable is void:
> grep-compilation-transform-finished-rules 
> 
> A new native byte compiled version of grep.el was created though.
> 
> Is the compilation error actually misleading? It seems as if I get the error
> 
> Source file ‘c:/Users/HoechtlJ/AppData/Local/Emacs/share/emacs/31.0.50/lisp/progmodes/grep.el’ newer
> than byte-compiled file; using older file
> Making completion list...
> compilation-start: Symbol’s value as variable is void: grep-compilation-transform-finished-rule 
> 
> using older file would indicate that it is using grep.elc but it seems Emacs does in fact use the NEW pathed
> grep.el 

To save yourself from all this trouble, patch grep.el in the source
tree, and then say "make install".  This will compile the patched
grep.el and will install it in the correct place.

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

From: Johann Höchtl <johann.hoechtl <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: visuweshm <at> gmail.com, 77732 <at> debbugs.gnu.org, ultrono <at> gmail.com
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Tue, 22 Apr 2025 17:45:51 +0200

[Message part 1 (text/plain, inline)]

Am Di., 22. Apr. 2025 um 17:30 Uhr schrieb Eli Zaretskii <eliz <at> gnu.org>:

> > From: Johann Höchtl <johann.hoechtl <at> gmail.com>
> > Date: Tue, 22 Apr 2025 17:11:49 +0200
> > Cc: eliz <at> gnu.org, visuweshm <at> gmail.com, 77732 <at> debbugs.gnu.org
> >
> > I extracted grep.el from grep.el.gz
> > I loaded the patch and applied it to grep.el
> > The hunks applied successfully
> >
> > I retried my rgrep opperation and got this in messages:
> >
> > Source file
> ‘c:/Users/HoechtlJ/AppData/Local/Emacs/share/emacs/31.0.50/lisp/progmodes/grep.el’
> newer
> > than byte-compiled file; using older file
> > Making completion list...
> > compilation-start: Symbol’s value as variable is void:
> grep-compilation-transform-finished-rules [2 times]
> >
> > So I renamed grep.el.gz to grep.elgz.o and grep.elc to grep.elc.o
> >
> > Still no luck but the compilation error remains compilation-start:
> Symbol’s value as variable is void:
> > grep-compilation-transform-finished-rules
> >
> > A new native byte compiled version of grep.el was created though.
> >
> > Is the compilation error actually misleading? It seems as if I get the
> error
> >
> > Source file
> ‘c:/Users/HoechtlJ/AppData/Local/Emacs/share/emacs/31.0.50/lisp/progmodes/grep.el’
> newer
> > than byte-compiled file; using older file
> > Making completion list...
> > compilation-start: Symbol’s value as variable is void:
> grep-compilation-transform-finished-rule
> >
> > using older file would indicate that it is using grep.elc but it seems
> Emacs does in fact use the NEW pathed
> > grep.el
>
> To save yourself from all this trouble, patch grep.el in the source
> tree, and then say "make install".  This will compile the patched
> grep.el and will install it in the correct place.
>

Would have to do that on Linux, the Windows machine is not apt for any
serious development. Maybe I can get around that hassle ..

[Message part 2 (text/html, inline)]

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

From: Paul Nelson <ultrono <at> gmail.com>
To: Johann Höchtl <johann.hoechtl <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77732 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Tue, 22 Apr 2025 17:52:39 +0200

[Message part 1 (text/plain, inline)]

Try opening the new grep.el, C-c C-e in the buffer, then C-x C-e with point
after the "defvar grep-compilation-transform-finished-rules" form

[Message part 2 (text/html, inline)]

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

From: Johann Höchtl <johann.hoechtl <at> gmail.com>
To: Paul Nelson <ultrono <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77732 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Wed, 23 Apr 2025 11:08:22 +0200

[Message part 1 (text/plain, inline)]

Am Di., 22. Apr. 2025 um 17:52 Uhr schrieb Paul Nelson <ultrono <at> gmail.com>:

> Try opening the new grep.el, C-c C-e in the buffer, then C-x C-e with
> point after the "defvar grep-compilation-transform-finished-rules" form
>

That worked
I did some tests with few matches, many matches
For my use-cases this fixes the bug.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Johann Höchtl <johann.hoechtl <at> gmail.com>
Cc: 77732-done <at> debbugs.gnu.org, visuweshm <at> gmail.com, ultrono <at> gmail.com
Subject: Re: bug#77732: grep-edit-buffer errors with incionsistent behaviour
Date: Sat, 26 Apr 2025 15:37:11 +0300

> From: Johann Höchtl <johann.hoechtl <at> gmail.com>
> Date: Wed, 23 Apr 2025 11:08:22 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, visuweshm <at> gmail.com, 77732 <at> debbugs.gnu.org
> 
> Am Di., 22. Apr. 2025 um 17:52 Uhr schrieb Paul Nelson <ultrono <at> gmail.com>:
> 
>  Try opening the new grep.el, C-c C-e in the buffer, then C-x C-e with point after the "defvar
>  grep-compilation-transform-finished-rules" form
> 
> That worked
> I did some tests with few matches, many matches 
> For my use-cases this fixes the bug.

Thanks, I've now installed this on the master branch, and I'm closing
this bug.

Previous Next

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