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

[Juri Linkov <juri@linkov.net>]

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

These are pipe filters.  You can see how complex is the command line
constructed in /bin/zgrep

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

Then you want two additional placeholders: for the command name and options?

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

In an older version of /bin/zgrep I see the text "OPTIONs are the same as for 'grep'."
I don't know about other versions.

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

There are only two possible values for grep-highlight-matches
whereas the number of possible values of the current placeholders
for regexps and filenames is infinite.

I think the rule should be the following: placeholders are needed only for
parameters provided by users, but for internal implementation parameters
it's enough to pre-compute command lines (and cache them).

PS: Somehow reminds me of endless discussions about distinctions
between `error' and `user-error' :)