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

> This is not a new issue, but seeing this:
> 
>   	if [ $detached = no ]; then
>   		branch_color="$ok_color"
>   	else
>   		branch_color="$bad_color"
>   	fi
>   	c="$branch_color$c"
>   
>   	z="$c_clear$z"
>   	if [ "$w" = "*" ]; then
>   		w="$bad_color$w"
>   	fi
>   	if [ -n "$i" ]; then
>   		i="$ok_color$i"
>   	fi
>   	if [ -n "$s" ]; then
>   		s="$flags_color$s"
>   	fi
>   	if [ -n "$u" ]; then
>   		u="$bad_color$u"
>   	fi
> +	if [ -n "$p" ]; then
> +		p="$c_clear$p"
> +	fi
> +	if [ -n "$sparse" ]; then
> +		sparse="$c_clear$sparse"
> +	fi
>   	r="$c_clear$r"
>   }
> 
> it makes me wonder if the more forward looking and future-proof way
> that is resistant to any future and random reshuffling like what
> 0ec7c23c (git-prompt: make upstream state indicator location
> consistent, 2022-02-27) did would be to make it a rule to maintain
> that there is no coloring by default, and when any of these tokens
> like w, i, s, ... are not empty, enclose them inside "color-on" and
> "color-off" sequence.
> 
> For example,
> 
>   	if [ "$w" = "*" ]; then
>   		w="$bad_color$w"
>   	fi
> 
> would mean $w, when it is "*", would cause gitstring to contain an
> asterisk that is painted in $bad_color, but ALSO causes whatever
> that happens to come AFTER $w in gitstring to be painted in the same
> color UNLESS it tries to protect itself.  Right now, $w may be
> immediately followed by $i, and $i does protect itself by prefixing
> with $ok_color, but if $i is empty, $w's coloring will extend to $s.
> 
> So, if we did this instead:
> 
> - 	z="$c_clear$z"
>   	if [ "$w" = "*" ]; then
> - 		w="$bad_color$w"
> + 		w="$bad_color$w$c_clear"
>   	fi
> 
> and make similar changes to everything else we see above, we
> probably can lose the ones that prefix with $c_clear, because each
> token that paints itself in unusual color is now responsible for
> returning the terminal state to normal with the $c_clear sequence
> after it is done with it.  We do not have to special case sparse, p,
> or r in this helper function at all if we go that route, no?
> 
> If the helper were written that way, then reshuffling the order of
> the tokens done in 0ec7c23c (git-prompt: make upstream state
> indicator location consistent, 2022-02-27) wouldn't have made the
> patch under discussion necessary at all, which is what I see is
> valuable from the "maintainability" point of view.
>