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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html