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

[Joakim Petersen <joak-pet@online.no>]

On 03/06/2022 23:16, Junio C Hamano wrote:
> After thinking it again, I actually am OK with the original coloring
> code structure.  The rule is "you always counter whatever color
> settings left behind by somebody who came before you".
> 
> As long as the color effect you use is not additive (e.g. if the
> final product is $a$b, and $a is prefixed with $c_red and $b is
> prefixed with $c_blue, an additive coloring scheme may end up
> painting b in purple), we'll save number of $c_clear we would need
> to emit.  Plain colors are probably not additive, but some
> attributes are, so this is more brittle than "always reset to the
> base state" rule, but it may be more desirable in practice.
> 
> I have no strong preference either way.  But if we are to go that
> route, we definitely need to make sure that the last element added
> to gitstring is followed by $c_reset, by doing something like the
> attached patch.  Currently, $r has unconditional $c_clear in front
> of it, and $upstream is never colored, and that is the only thing
> that is saving us from leftover color bleeding into whatever comes
> after the prompt.

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.