GNU bug report logs - #20728
25.0.50; grep and grep-find templates should have a place holder for the --color argument

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 20728 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#20728: 25.0.50; grep and grep-find templates should have a
 place holder for the --color argument
Date: Mon, 8 Jun 2015 01:22:31 +0300

On 06/07/2015 01:04 AM, Juri Linkov wrote:

> Thanks for mentioning zrgrep!  I noticed that it's broken now and fixed
> with the patch that let-binds grep-highlight-matches before calling
> grep-compute-defaults since now it's computed here.

No problem. Could you explain what those filters are, the ones the 
comment says zgrep puts into output?

> String replacement is too unreliable approach.

I meant template substitution, like in grep-expand-template.

Not sure what to do about grep-default-command, but if leaving it as-is 
is not an option, we can reasonably decide that the grep-command was the 
symbol at the beginning of the previous command.

> But I see no problem with
> both zrgrep and the code where you want to parse the output programmatically,
> to remember the computed command lines in defvar variables such as
> zgrep-find-command, zgrep-find-template, etc. to not compute them every
> time the command is called.

Again, why have zgrep-find-template, when grep-find-template could have 
a (new) placeholder for grep-command? Do zgrep and grep take different 
options?

> When parameters don't vary between command calls (as regexps and files do)
> then I think it's better to prepare them in the command line templates.

Since grep-command and grep-highlight-matches can vary between calls, 
should we make a template placeholder for them?

Previous Next

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