On Tue, Apr 2, 2013 at 5:26 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy  <pclo...@gmail.com> writes:
>> This is not simply convenient over %C(auto,xxx). Some placeholders
>> (actually only one, %d) do multi coloring and we can't emit a multiple
>> colors with %C(auto,xxx).
>> Signed-off-by: Nguyễn Thái Ngọc Duy <pclo...@gmail.com>
>> ---
>>  Documentation/pretty-formats.txt |  3 ++-
>>  pretty.c                         | 15 +++++++++++++--
>>  2 files changed, 15 insertions(+), 3 deletions(-)
>> diff --git a/Documentation/pretty-formats.txt 
>> b/Documentation/pretty-formats.txt
>> index 66345d1..8734224 100644
>> --- a/Documentation/pretty-formats.txt
>> +++ b/Documentation/pretty-formats.txt
>> @@ -154,7 +154,8 @@ The placeholders are:
>>    adding `auto,` at the beginning will emit color only when colors are
>>    enabled for log output (by `color.diff`, `color.ui`, or `--color`, and
>>    respecting the `auto` settings of the former if we are going to a
>> -  terminal)
>> +  terminal). `auto` alone (i.e. `%C(auto)`) will turn on auto coloring
>> +  on the following placeholder.
>>  - '%m': left, right or boundary mark
>>  - '%n': newline
>>  - '%%': a raw '%'
> I like this at the conceptual level.
> If you say "%C(auto)%C(red)Text%C(auto)%C(reset)", does it do the
> right thing when the output is not capable of color?

The above should have written "will turn on auto coloring on the
following _textual_ placeholder". I didn't intend %C(auto) to be
followed by %C(color) as it's already covered by %C(auto,red). But of
course we could make it work too.

> I am a bit worried if the placement of the "grab c->auto_color to
> decide if we paint for this round and reset it" is optimial and will
> stay optimal as we enhance format_commit_one() later.  Is there a
> reason why we do not do that at the beginning of the function,
> before "these are independent of the commit" comment?

No reason. Will move.

> Side note.  Should the new field called "auto_color_next" or
> something?

Yep, sounds better than my variable name.
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