[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20728: 25.0.50; grep and grep-find templates should have a place hol

From: Dmitry Gutov
Subject: 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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]