Re: [PATCH 2/2] git-prompt.zsh: introduce thin ZSH wrapper

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, May 11, 2013 at 11:25 AM, Ramkumar Ramachandra
<artagnon@xxxxxxxxx> wrote:
> To facilitate a colored prompt in ZSH, write a thin wrapper around
> git-prompt.sh, factoring out and overriding the coloring logic.  Since
> ZSH lacks a PROMPT_COMMAND, instruct the user to execute __git_ps1
> inside precmd().

I think this is two logical changes into one.

> --- /dev/null
> +++ b/contrib/completion/git-prompt.zsh
> @@ -0,0 +1,59 @@
> +# git prompt support for zsh: wrapper around git-prompt.sh
> +#
> +# To enable:
> +#
> +#    1) Copy this file and git-prompt.sh to ~/.zsh/prompt
> +#    2) Add the following lines to your .zshrc:
> +#
> +#          source ~/.zsh/prompt/git-prompt.zsh
> +#          GIT_PS1_SHOWCOLORHINTS=true
> +#          precmd () { __git_ps1 "%n|" ":%~$ " "%s" }
> +#
> +#    3) You can now add the following to ~/.zshrc and expect the
> +#       characters to be displayed in color:
> +#
> +#          GIT_PS1_DESCRIBE_STYLE=branch
> +#          GIT_PS1_SHOWUPSTREAM=auto
> +#          GIT_PS1_SHOWDIRTYSTATE=true
> +#          GIT_PS1_SHOWUNTRACKEDFILES=true
> +
> +test -z "$script" && script="$(dirname ${funcsourcetrace[1]%:*})"/git-prompt.sh
> +ZSH_VERSION='' . "$script"

I've been thinking that this method of loading the script is not the
best; we should probably have a list of locations where distributions
usually put this file. So if we could avoid the creation of of a new
file, that would be great.

> +autoload colors
> +colors
> +
> +__git_ps1_colorize_gitstring ()
> +{
> +       local c_red='%F{red}'
> +       local c_green='%F{green}'
> +       local c_lblue='%F{blue}'
> +       local c_clear='%f'
> +       local bad_color=$c_red
> +       local ok_color=$c_green
> +       local branch_color="$c_clear"
> +       local flags_color="$c_lblue"
> +       local branchstring="$c${b##refs/heads/}"

This is the only real difference with bash colors, no? I think it's
overkill to create a new file, and load the old one, only to override
part of a function. We should probably start with everything in the
same file, and only later if we find it's necessary, split.

> +       if [ $detached = no ]; then
> +               branch_color="$ok_color"
> +       else
> +               branch_color="$bad_color"
> +       fi
> +
> +       gitstring="$branch_color$branchstring$c_clear"
> +
> +       if [ "$w" = "*" ]; then
> +               gitstring="$gitstring$bad_color$w"
> +       fi
> +       if [ -n "$i" ]; then
> +               gitstring="$gitstring$ok_color$i"
> +       fi
> +       if [ -n "$s" ]; then
> +               gitstring="$gitstring$flags_color$s"
> +       fi
> +       if [ -n "$u" ]; then
> +               gitstring="$gitstring$bad_color$u"
> +       fi
> +       gitstring="$gitstring$c_clear$r$p"
> +}
> --

-- 
Felipe Contreras
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]