Re: bash completion with colour hints

[Michael J Gruber <git@drmicha.warpmail.net>]

Junio C Hamano venit, vidit, dixit 27.09.2012 08:53:
> Simon Oosthoek <soosthoek@nieuwland.nl> writes:
> 
>> I read the guide and now I have some questions:
>>
>> - It suggests to use the oldest commit that contains the "bug" and can
>> support the fix. This would be the very first mention of __git_ps1
>> function I think commit d3d717a4ad0c8d7329e79f7d0313baec57c6b585
> 
> You could claim that the lack of coloring is a bug, but nobody
> complained about it so far (and I personally hate coloring in
> prompts as they are distracting noise, and would reject a patch if
> it weren't made conditional), so I would think this is more about
> "adding a feature the users can choose to use but they do not have
> to".
> 
> We do not usually add new features to maintenance tracks, so the
> result of applying the patch does not have to be merge-able to maint
> or amything older.  I would base the patch on v1.7.12 (the latest
> stable release) if I were you.
> 
>> - I read that git-prompt.sh is meant to support bash and zsh, I have
>> only tested it on bash. Should I attempt to test it on zsh or is there a
>> kind person with zsh as his/her shell to test it for me?

Actually, the instructions in the prompt script are not complete for zsh
(you need to activate expansion in the prompt), and I think there is
some breakage because bash uses "\h" etc. for PS1 format specifiers
whereas zsh uses '%h', and so the '%' in the prompt is a problem for zsh.

> That is something you should ask on list, like you did here, but the
> most effective way to do so is do so when you send a patch you
> worked on and tested with bash.  Say "I've tested it only with bash;
> can you please take a look?" and Cc the folks you find in the output
> of "git log contrib/completion/" who worked on making it workable
> with zsh.
> 

Additionally, there have been several attempts already for prompt. So
I'd suggest you check the list archives to see whether you addressed the
issues which were raised back then. I've actually been toying with that
myself lately. A few hints:

- You need to escape the escapes '\[', i.e. tell the shell that color
escapes produce zero length output, or else line wrapping is distorted.

- Bash interpretes '\' only when PS1 is assigned, not when an expansion
in PS1 produces it.

- Some don't like it colorful, so the coloring needs to depend on a
config setting or env variable.

- Coloring should be consistent with other coloring in Git, such as
'status -s -b'.

- Coloring provides the way to make the prompt characters analogous to
'status -s -b' because a green 'M' is different from red 'M', and is
much clearer then having to remember '+' vs. '*' (so there is a logic in
that).

>From trying myself, I'm convinced that you need a clever combination of
PROMPT_COMMAND and PS1 to make this work. Setting PS1 in PROMPT_COMMAND
is probably a no-go because that makes it difficult to customize PS1. I
have something in the works which reproduces the current prompt but need
to clean it up further. The actual coloring would require setting a lot
of variables which communicate data from PROMPT_COMMAND to PS1, and I
actually don't like that.

An alternative approach would be:

- Tell users to activate git prompt by doing something like

PROMPT_COMMAND='__git_prompt "[\u@\h \W (%s)]\$ '

rather than the current

PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '

- set PS1 from __git_prompt

I'm not sure about the performance implications of re-setting PS1 on
(before) each prompt invocation, though. Would that be OK?

Michael