Re: [PATCH v3] git-prompt: make colourization consistent

Joakim Petersen [off-list ref] writes:

There might be something I'm not seeing, but having it so each element
counters whatever colour left by the preceding element seems less
intuitive when adding or moving elements in the final $gitstring. Adding
an element will then require going into __git_ps1_colorize_gitstring,
even when it is not intended to be colourized. All existing uncoloured
elements will also need to be prefixed to protect against colour bleed
from being moved around. I'm partial to the idea of each coloured
element clearing its own colour.

I think that each makes sense in its own way.  Depending on what
assumption we can make on the use of terminal attributes, one can
produce shorter output than the other.

For example, if you have 3 things, A, B, and C, that are shown in
this order, the "clear after yourselves" scheme would give

	gitstring=<red>A<clear><blue>B<clear><green>C<clear>

while "clear the slate for yourself before you draw, the framework
will clear the effect of the last one" scheme can give

	gitstring=<red>A<blue>B<green>C<clear>

if we know that no additive terminal attributes are used, and the
latter gives a shorter output.

If we need to support some additive ones (like "reverse"), on the
other hand, and if each element is independent (i.e. "clear the
slate for me" cannot use the knowledge of what the previous one
did), then we have to write

	gitstring=<red>A<clear><blue>B<clear><green>C<clear>

for the latter, which becomes more verbose (but is the same as the
"each is on its own, clear after yourselves" version).

I have no strong preference either way myself.  "each on its own"
might be conceptually simpler and easier to understand and explain
what is going on.

Thanks.