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

[Juri Linkov <juri@linkov.net>]

> 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.