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

[Dmitry Gutov]

On 06/29/2015 05:49 PM, Eli Zaretskii wrote:

> > > We could, if we want to test Grep's output ourselves.  That is, we
> > > will have to decide when to bind it to nil and when to non-nil,
> >
> > What do you mean by "test"?
>
> "Examine".  The behavior with pipes, files, consoles, and ptys is
> different.

I don't understand this. Grep's output happens after we bind, or not 
bind, this variable. So we can't test in beforehand (or do you mean in 
`grep-compute-defaults'?).

> > My point is, we have to decide whether to highlight matches or not, if
> > only to be compatible with Windows. And by "we", I mean in the
> > implementation of each given command.
>
> Yes, the alternative is to do everything in Lisp, and then use only
> "--color=no" or "--color=always", as appropriate.

That's what I'm proposing. This seems simpler and less error-prone. So 
this discussion is about the possible downsides.

> > Whether we want a given command to use a colorized Grep output, is not
> > dependent on the OS, is it?
>
> I don't think so.  But it might depend on the values of grep-program
> etc., i.e. on user customizations.  Users might want to put shell
> scripts or pipelines there.

Well, okay. If it's a significant use case, we might want to continue 
supporting it.

On the other hand, we might want to choose to set 
`grep-highlight-matches' to `always' in grep-compute-defaults, 
irrespective of the OS.

So that every command that knows it does not need the ANSI codes, will 
bind this variable to nil without relying on auto-detection thanks to 
calling Grep via a pipe. Then we won't have to test on Windows to find 
bugs like that.

And if a user customized grep-program, etc, to unexpectedly postprocess 
Grep ouput using a pipe, they can customize `grep-highlight-matches' to 
`auto' as well.