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:


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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to