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
Junio C Hamano venit, vidit, dixit 01.10.2012 23:09:
Simon Oosthoek s.oosth...@xs4all.nl 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
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 that
Michael J Gruber g...@drmicha.warpmail.net 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
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 point
Simon Oosthoek s.oosth...@xs4all.nl 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 \]
On 09/28/2012 07:58 PM, Junio C Hamano wrote:
Simon Oosthoek soosth...@nieuwland.nl 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
+}
On 01/10/12 19:16, Junio C Hamano wrote:
Simon Oosthoek soosth...@nieuwland.nl writes:
On 09/28/2012 07:58 PM, Junio C Hamano wrote:
Simon Oosthoek soosth...@nieuwland.nl writes:
+# __git_ps1_pc accepts 0 arguments (for now)
+# It is meant to be used as PROMPT_COMMAND, it sets PS1
Junio C Hamano gits...@pobox.com 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
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
Simon Oosthoek soosth...@nieuwland.nl 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?
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
Simon Oosthoek s.oosth...@xs4all.nl 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.
Simon Oosthoek soosth...@nieuwland.nl 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
14 matches
Mail list logo
