|
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?
[Prev in Thread] | Current Thread | [Next in Thread] |