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.
