Joakim Petersen <joak-pet@xxxxxxxxx> 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.
