Subject: Re: [RFC/PATCH 2/2] status -s: obey color.status

From: Michael J Gruber <[email-masked]>
Date: Fri, 27 Nov 2009 10:17:00 +0100

Junio C Hamano venit, vidit, dixit 27.11.2009 06:15:
> Michael J Gruber <[email-masked]> writes:
> 
>> * Should I rename wt-status.c's color() into something more unique when
>>   I export it?
> 
> Is it an option to instead move short_unmerged(), short_status() and
> friends to wt-status.c from builtin-commit.c?  It's been quite a while
> since I worked on the code, so I don't recall why it needs such cross
> references at low level between two files.

I didn't notice, but I'll look into it during the rewrite.

>> * Is there any policy regarding use of putchar/puts vs. printf?
> 
> J6t addressed it.  You have mixture of putchar(' ') and printf(" ") which
> looks somewhat funny ;-)

;) I'm happy with printf("c"), I just thought someone would find printf
overkill for a format less char.

>> * The way it is done now I "color" a space, otherwise one would need to
>>   break down the print statements even more. Since we always color the
>>   foreground only it is no problem, is it?
> 
> Some people do configure to use "reverse".  For example, I have:
> 
>     [diff.color]
>             old = red reverse
>             whitespace = blue reverse
> 
>     [status.color]
>             updated = green
>             changed = red
>             untracked = blue reverse
> 
> The output should be consistent between long and short format (I do not
> offhand recall what we do for the long format, though).

Oh, I didn't know about reverse. In this case I have to change the code
and leave the space alone. (The one between ?? and the filename.) Will do.

In the long format, only the file name is colored. Note that in the
short format, it does not make sense to color the file name because one
line may represent two pieces of status information. That is why I color
the two status letters and not the file name.

Michael