Re: [PATCH 0/1] Colorize some errors on stderr

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

> Now, what would be possible solutions for this?
>
> - introduce `int fd` in `want_color()` (and callees) so that we can make
>   a distinction whether we want to detect whether stdout or stderr is connected
>   to a tty
>
> - introduce a separate `want_color_stderr()` (we still would need to decide
>   whether we want a config setting for this)

Between the above two, there probably aren't so big a difference, but
in order to avoid disrupting existing callers of want_color() while
possibly sharing as much code between the old and new callers,
perhaps:

	extern int want_color_fd(int fd, int colorbool);
	#define want_color(colorbool) want_color_fd(1, (colorbool))
	#define want_color_stderr(colorbool) want_color_fd(2, (colorbool))

We should honor configuration at two levels, just like the colors on
stdout, i.e. color in which individual items are painted (e.g.
color.diff.filename, color.advice.hint) and whether we use colors in
UI at all (e.g. color.ui).  I do not think it is necessary or even
at the right granularity to allow settings like "do color stdout but
do not color errors".

> - not color stderr, ever

This is my personal preference, but that does not and should not
carry too much weight ;-)