On Nov 16, 2010, at 2:43 AM, Michael J Gruber wrote: > Kevin Ballard venit, vidit, dixit 16.11.2010 10:07: >> On Nov 16, 2010, at 12:11 AM, Sebastien Douche wrote: >> >>> On Tue, Nov 16, 2010 at 00:14, Kevin Ballard <kevin@xxxxxx> wrote: >>>> I take it back. We can use PROMPT_COMMAND for this, to set up variables >>>> containing what you want. >>>> >>>> Something like the following should work: >>> >>> Hi Kevin, >>> good job! I looked the git prompt and I'm a bit disappointed with the >>> combination, ps1 can show many items: >>> >>> # >>> % >>> + >>> * >>> $ >>> REBASE-i| >>> REBASE-m| >>> MERGING| >>> BISECTING| >>> < > <> (or u+count u-count u+countu-count) >>> >>> Each item is "optional", so you can have REBASE-i| with * and +, or >>> only *. It seems to complicated to wrap all items (I think of the >>> verbose mode for upstream branches). Maybe coding a lua (or Python) >>> prompt with a config file. >> >> In the end you need to stuff everything that needs a distinct color into its >> own shell variable. You could just extend the shell function that's doing that >> right now, or you could write a script in another language that emits a >> shell-quoted set of variables suitable for evaling by the shell. > > Also, you should get away from parsing individual characters in > __git_ps1. Characters like + and - are valid in branch names. Coloring > them within the name is not quite intended. That's actually handled with the PROMPT_COMMAND version. It uses git rev-parse --symbolic-full-name --abbrev-ref=loose HEAD to get a copy of the branch name, and then removes that from the __git_ps1 output. Everything that's left is part of the status. > I guess the only way is to produce colors within __git_ps1 (based on an > option). Also, colors would allow to use the same status letters as "git > status -s". That's how my original version worked (though it had the flaw you mentioned above). The PROMPT_COMMAND version was motivated by the fact that the color escapes need to be embedded directly in PS1 so \[ and \] can be used to instruct bash to treat them as non-printable characters. If the color codes are emitted by __git_ps1 directly, then bash will incorrectly treat them as printable characters and wrap at the wrong spot. What would be nice is a mode for __git_ps1 that emits a string suitable for eval by bash that gives every status indicator its own variable. This could be enabled by using something like $(__git_ps1 --shell-quote " (%s)"). In this case, __git_ps1 would break the format string into two parts, by splitting around the %s, and put those in the left/right guard variables. -Kevin Ballard-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html