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

Previous Next

Full log

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)]

Previous Next

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