From: Jeff King <peff@peff.net>
Date: Wed, 10 Jul 2013 06:11:15 GMT
Subject: Re: [PATCH 3/3] wt-status: use "format" function attribute for status_printf
Message-ID: <20130710061115.GA11741@sigill.intra.peff.net>
In-Reply-To: <7vehb7t0zs.fsf@alter.siamese.dyndns.org>

On Tue, Jul 09, 2013 at 10:52:55PM -0700, Junio C Hamano wrote:

> > The patch to do it is below, but I actually think an explicit blank-line
> > function like:
> >
> >   status_print_empty_line(s, color);
> >
> > would be more obvious to a reader.
> 
> I noticed that all but one can be dealt with with
> 
>     perl -p -i -e 's/status_printf_ln\((.*), ""\);/status_printf($1, "\\n");/'
> 
> That is,
> 
> -	status_printf_ln(s, GIT_COLOR_NORMAL, "");
> +	status_printf(s, GIT_COLOR_NORMAL, "\n");
> 
> which does not look _too_ bad.

Is that correct, though? The reason we have *_printf_ln in the
first place is that we want to do:

  ${color}content${reset}\n

to make sure that the newline does not happen inside the colorization.
At least that is why I added color_printf_ln long ago.

It would probably improve the code quite a bit if we could simply feed
multi-line strings to status_printf, and have it stick the colorization
in the correct spot of each line. And hmm...it kind of looks like
status_vprintf already does that. Now I'm puzzled why many of these do
not simply include the newline along with the string being printed.

> There is one instance that needs this, though.
> 
> -		status_printf(s, color(WT_STATUS_HEADER, s), "");
> +		status_printf(s, color(WT_STATUS_HEADER, s), "%s", "");

Hmm, yeah. It cannot be combined with the lines following it, either,
because they are using different colorization.

If you want to keep refactoring this, I don't mind, but I kind of feel
like we are going down a rabbit hole for very little gain.

-Peff