Re: Colors in __git_ps1

Re: Colors in __git_ps1

[Simon Oosthoek]

Dear Mantas,

On 07/10/14 18:18, Mantas Mikulėnas wrote:
> There was a question in #git recently on why __git_ps1 from
> git-prompt.sh does not allow colors in "$PS1 mode".
>
>  From what I see, commit 1bfc51ac8141 talks about the need for \[ and
> \] assignments in $PS1, and commit cf4cac4cfc13 says that PS1 mode
> turns off color support since \[ and \] won't work; as I understand
> it, this is because bash will output literal "\[" if __git_ps1 tries
> to echo it.
>
> Internally, \[ and \] are translated by bash into 0x01 and 0x02 before
> passing the final string to readline. So there *is* a way to achieve
> the same effect in "PS1 mode" – __git_ps1 just needs to echo \001 and
> \002 before & after the color codes, and readline will interpret them
> correctly when calculating the prompt width. For example, echo
> $'foo\001\e[1m\002bar'.
>
> Might be worth considering, even if $PS1 mode is inferior to
> $PROMPT_COMMAND mode for other reasons.
>

I would actually prefer the PS1='$(__git_ps)' like way, as it is more 
generic and intuitive when you know generic Bourne shell ways.

The reason to go for PROMPT_COMMAND was that it appears to be the only 
way to set the PS1 prompt and let bash keep track of the length of the 
prompt properly. This is needed to allow browsing the bash history with 
long(er than width of the terminal) command lines without the terminal 
getting messed up.
And I'm still not sure PROMPT_COMMAND mode fixes this properly, but it 
passed the tests where command substitution mode failed.

IMHO the way colours are now implemented could very well be considered a 
workaround for a bug in bash. Only I'm not skilled enough (or have 
enough time) to get to the bottom of it...

I hope this answers your question.

Cheers

Simon