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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 16, 2018, 19:21 UTC
Message-ID: <xmqqwozc68r2.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <cover.1518783709.git.johannes.schindelin@gmx.de>

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

Show 8 quoted lines

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