GNU bug report logs -
#20728
25.0.50; grep and grep-find templates should have a place holder for the --color argument
Previous Next
Reported by: Dmitry Gutov <dgutov <at> yandex.ru>
Date: Wed, 3 Jun 2015 23:44:01 UTC
Severity: normal
Found in version 25.0.50
Fixed in version 25.1
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> That's what zrgrep does, and its quite clunky. And if we have code to
> pre-compute commands and templates (which takes several external program
> calls), it's kind of silly to redo that again each time certain commands
> are called.
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.
> Do you know if zrgrep has a good reason for it? Like, it there are
> platforms where we have to use different calling conventions for grep and
> zgrep? Otherwise, we could simply substitute grep-program value in
> the commands.
String replacement is too unreliable approach. 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.
>> In case when users customize grep-highlight-matches interactively,
>> its defcustom should compute new command lines using grep-compute-defaults.
>
> Do you think, overall, it will be the better approach?
Well, there are two levels of parametrization in grep.el:
1. grep-compute-defaults uses %s-substitutions to prepare
command line templates with placeholders.
2. templates are expanded on every command call with regexps and files.
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.
This bug report was last modified 10 years and 4 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.