Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

2012-10-08 Thread Simon Oosthoek
Hi Junio I hope you found my patches, if not, I'll try to send them out again. (Unfortunately my current mail setup is a mess and I need time to figure out what to fix...) As for the zsh support, I found out a little bit more. ZSH doesn't have a variable like PROMPT_COMMAND in bash. The precm

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

2012-10-02 Thread Junio C Hamano
Simon Oosthoek writes: > ... This is > prevented (and quite the norm in static PS1 strings) by enclosing the > terminal code for color inside \[ and \] so bash doesn't count these and > what is in between them in the length of the prompt string. Ah, OK, and these \[ things \] behave like other m

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

2012-10-02 Thread Simon Oosthoek
On 02/10/12 19:01, Junio C Hamano wrote: > If your goal is to use PROMPT_COMMAND and not PS1, then yes between > the two definitions of PROMPT_COMMAND above, the latter may look > simpler. But that does not explain why you want to prefer it over > PS1 in the first place, which was the central poin

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

2012-10-02 Thread Junio C Hamano
Michael J Gruber writes: > Junio C Hamano venit, vidit, dixit 01.10.2012 23:09: > >> Confused >> > > The "problem" (as far as I see) is only: What user interface do we want > to expose to the user, or rather, do we want to expose the user to ;) > > So far, we say: > > #1) Copy this file

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

2012-10-02 Thread Simon Oosthoek
On 10/02/2012 09:38 AM, Michael J Gruber wrote: The longer I read your explanation, the less useful the "PC mode" sounds like, at least to me. So why does an user even want to use such a mechanism, instead of PS1? And even if the user wants to use it by doing \w, \u etc. himself, she can do tha

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

2012-10-02 Thread Michael J Gruber
Junio C Hamano venit, vidit, dixit 01.10.2012 23:09: > Simon Oosthoek writes: > >> It's possible to set PS1 to nothing and print a string from >> PROMPT_COMMAND, but then you miss out on all the features of the PS1 >> interpretation by bash and compared to the use of __git_ps1 at the >> moment, i

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

2012-10-01 Thread Junio C Hamano
Simon Oosthoek writes: > It's possible to set PS1 to nothing and print a string from > PROMPT_COMMAND, but then you miss out on all the features of the PS1 > interpretation by bash and compared to the use of __git_ps1 at the > moment, it has to put out quite a different string. Because if you lik

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

2012-10-01 Thread Simon Oosthoek
On 01/10/12 21:54, Junio C Hamano wrote: > Now you lost me. The documentation of PROMPT_COMMAND in "man bash" > says this: > >PROMPT_COMMAND > If set, the value is executed as a command prior to > issuing each primary prompt. > > So yes, if you say "PROMPT_COM

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

2012-10-01 Thread Junio C Hamano
Simon Oosthoek writes: > On 01/10/12 21:13, Junio C Hamano wrote: > >> Hrm, let me ask a stupid question. Why do we even need __git_ps1_pc >> in the first place? Wouldn't it be just the matter of >> >> PROMPT_COMMAND='__git_ps1 "%s"' >> >> once you have __git_ps1 that works? > > Apart fr

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

2012-10-01 Thread Simon Oosthoek
On 01/10/12 21:13, Junio C Hamano wrote: > Hrm, let me ask a stupid question. Why do we even need __git_ps1_pc > in the first place? Wouldn't it be just the matter of > > PROMPT_COMMAND='__git_ps1 "%s"' > > once you have __git_ps1 that works? Apart from one small detail, PS1 must be set

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

2012-10-01 Thread Junio C Hamano
Junio C Hamano writes: >> I agree that it's ugly. How about the following: >> >> I modified __git_ps1 to work both in PROMPT_COMMAND mode and in that >> mode support color hints. >> >> This way there's one function, so no overlap. > > I think the logical progression would be > > - there are part

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

2012-10-01 Thread Simon Oosthoek
On 01/10/12 19:16, Junio C Hamano wrote: > Simon Oosthoek writes: > >> On 09/28/2012 07:58 PM, Junio C Hamano wrote: >>> Simon Oosthoek writes: >>> +# __git_ps1_pc accepts 0 arguments (for now) +# It is meant to be used as PROMPT_COMMAND, it sets PS1 +__git_ps1_pc () +{

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

2012-10-01 Thread Junio C Hamano
Simon Oosthoek writes: > On 09/28/2012 07:58 PM, Junio C Hamano wrote: >> Simon Oosthoek writes: >> >>> +# __git_ps1_pc accepts 0 arguments (for now) >>> +# It is meant to be used as PROMPT_COMMAND, it sets PS1 >>> +__git_ps1_pc () >>> +{ >>> + local g="$(__gitdir)" >>> + if [ -n "$g" ]; the

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

2012-10-01 Thread Simon Oosthoek
On 09/28/2012 07:58 PM, Junio C Hamano wrote: Simon Oosthoek writes: +# __git_ps1_pc accepts 0 arguments (for now) +# It is meant to be used as PROMPT_COMMAND, it sets PS1 +__git_ps1_pc () +{ + local g="$(__gitdir)" + if [ -n "$g" ]; then +... + fi +} This looks awfully sim

Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

2012-09-28 Thread Junio C Hamano
Simon Oosthoek writes: > +# __git_ps1_pc accepts 0 arguments (for now) > +# It is meant to be used as PROMPT_COMMAND, it sets PS1 > +__git_ps1_pc () > +{ > + local g="$(__gitdir)" > + if [ -n "$g" ]; then > +... > + fi > +} This looks awfully similar to the existing code in __git_ps1