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

[Dmitry Gutov <dgutov@yandex.ru>]

On 06/28/2015 05:35 PM, Eli Zaretskii wrote:

>>> Isn't it the other way around: Windows wants 'always' (except when it
>>> doesn't, see below), while others want 'auto'?
>>
>> When will `always' not work for the others?
>
> I answered that below:

No: when will a given command's behavior on other operating systems be 
wrong if it was just written to work on Windows (and thus uses either 
`always' or nil, not `auto')?

>>> As to when you won't want 'always': it's when Grep is invoked as part
>>> pf a pipeline, where it's not the last part,

Do we have any such commands? If so, would it hurt them to have to bind 
`grep-highlight-matches' to nil?

>>> or when the Lisp program
>>> that invokes it wants to interpret the results, as opposed to showing
>>> them to the user.

Again, any such command will need to bind `grep-highlight-matches' to 
nil, to work on Windows. Or neutralize some other way the value `always' 
that it gets set to automatically, on Windows and DOS.

>> I'd want `nil' in that case, right?
>
> In which case?  And what do you mean by 'nil' in this context?  We are
> talking about the value of the --color= Grep option, don't we?

In either case: when the pipeline ends with something other than Grep, 
or when we'll process the output programmatically, and don't need the 
ANSI codes.

I'm talking about the value of `grep-highlight-matches'.

>> And I'd have to specify it explicitly anyway, if I want
>> compatibility with Windows.
>
> You lost me.

See above.

>> So, why do we use `auto'?
>
> My guess would be: because it mostly does what we want, AUTOmatically:
> it produces SGR color sequences when Grep is run as a subprocess via a
> pty, and does not produce them when Grep's output is a pipe.

Do we even have Grep-related commands that use a pipeline that doesn't 
end with Grep?