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

[Dmitry Gutov]

On 06/10/2015 02:32 AM, Juri Linkov wrote:

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

I see, thanks. Apparently, the upshot is that --color=auto doesn't work.

The nil value of grep-highlight-matches should still work, though.

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

Yep!

By the way, <C> is already used to conditionally pass '-i'. We can reuse 
it to pass one more option. So, minus one new placeholder.

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

Let's try it, then.

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

Right. That means that you can't precompute regexps and filenames, at 
all. That does not, however, mean that you *have to* precompute 
everything else.

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

Even if "internal" parameters vary between commands that use the same 
template?

I disagree. If we can expand those parameters dynamically, we should.

By the way, `grep-highlight-matches' is an option that the user can 
change via Customize, but the setter only calls `grep-apply-setting'.

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

I don't remember, but `user-error' won, hasn't it? The main question now 
regarding it, is find and change all applicable uses of `error'.