Use of vcs_info

Use of vcs_info

[Benjamin R. Haskell]

I don't fully understand how best to use vcs_info.

My first question is:  what's with the weird $vcs_info_msg_#_ variable 
names? (Why not an array?)

But, beyond that, my big question is: Is there a way to access the 
vcs_comm variable that's sprinkled throughout the VCS_Info functions 
directory?  My guess is that the easiest thing for me to do would be to 
simply remove the 'local -Ax vcs_comm' line in vcs_info, but everything 
else is so well-organized that I figured I must just be missing some way 
to get that variable exported.

The most helpful page so far was Frank Terbeck's prompt_ft_setup 
page[1].  Otherwise I'd've had to have read even more of the code to 
figure out the various

zstyle ':vcs_info:*' actionformats ''
zstyle ':vcs_info:*' formats ''
zstyle ':vcs_info:(sv[nk]|bzr):*' branchformat

tricks that are available.

I already do a bunch of stuff in my pre_cmd and pre_exec functions, and 
I'd really like to just add some things to my prompt conditioned on 
whether (for example) the current git repo is in a rebase, and maybe a 
shortened version of the branch name.  So, is there a way to get the 
info out of vcs_info?

-- 
Best,
Ben

[1] http://ft.bewatermyfriend.org/comp/zsh/functions/prompt_ft_setup.html

Re: Use of vcs_info

[Mikael Magnusson]

On 22 March 2010 04:09, Benjamin R. Haskell <zsh@benizi.com> wrote:
> I don't fully understand how best to use vcs_info.
>
> My first question is:  what's with the weird $vcs_info_msg_#_ variable
> names? (Why not an array?)
>
> But, beyond that, my big question is: Is there a way to access the
> vcs_comm variable that's sprinkled throughout the VCS_Info functions
> directory?  My guess is that the easiest thing for me to do would be to
> simply remove the 'local -Ax vcs_comm' line in vcs_info, but everything
> else is so well-organized that I figured I must just be missing some way
> to get that variable exported.
>
> The most helpful page so far was Frank Terbeck's prompt_ft_setup
> page[1].  Otherwise I'd've had to have read even more of the code to
> figure out the various

Did you read the vcs_info section in the man page? I haven't but it's
quite long so it probably covers everything :).

-- 
Mikael Magnusson

Re: Use of vcs_info

[Frank Terbeck]

Benjamin R. Haskell wrote:
> I don't fully understand how best to use vcs_info.

First just to make sure: you did find the documentation in
zshcontrib(1), right? (man zshcontrib | less -p GATHER)

> My first question is:  what's with the weird $vcs_info_msg_#_ variable 
> names? (Why not an array?)

Those variables are exported (there was a reason for it, I don't
remember what it was exactly). And you can't export arrays.

> But, beyond that, my big question is: Is there a way to access the 
> vcs_comm variable that's sprinkled throughout the VCS_Info functions 

You shouldn't.
That's an associative array to allow bidirectional communication between
various parts of vcs_info. If you want to know some internals, I could
explain them, but for *using* vcs_info, you do not need to know anything
about that particular variable.

> directory?  My guess is that the easiest thing for me to do would be to 
> simply remove the 'local -Ax vcs_comm' line in vcs_info, but everything 
> else is so well-organized that I figured I must just be missing some way 
> to get that variable exported.

What do you need that variable for? Maybe if you'd explain what you want
to do, I'd have a suggestion.

> The most helpful page so far was Frank Terbeck's prompt_ft_setup 
> page[1].  Otherwise I'd've had to have read even more of the code to 
> figure out the various
>
> zstyle ':vcs_info:*' actionformats ''
> zstyle ':vcs_info:*' formats ''
> zstyle ':vcs_info:(sv[nk]|bzr):*' branchformat
>
> tricks that are available.
>
> I already do a bunch of stuff in my pre_cmd and pre_exec functions, and 
> I'd really like to just add some things to my prompt conditioned on 
> whether (for example) the current git repo is in a rebase, and maybe a 
> shortened version of the branch name.  So, is there a way to get the 
> info out of vcs_info?

Yes, there is.
The "shortened" make it a little trickier, though. In currently released
code (4.3.7), you can make one format to just be "%b" and change the
corresponding variable after calling vcs_info your precmd function.

Vcs_info in CVS has hooks. The manual explains them in some detail and
gives some simpler examples. You can use a "set-message" hook to get
full control over what will be inserted for the branch-name. That is
probably what you want.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: Use of vcs_info

[Benjamin R. Haskell]

On Mon, 22 Mar 2010, Frank Terbeck wrote:

> Benjamin R. Haskell wrote:
> > I don't fully understand how best to use vcs_info.
> 
> First just to make sure: you did find the documentation in 
> zshcontrib(1), right? (man zshcontrib | less -p GATHER)

I could've sworn I'd looked in zshall.  Apparently not.  Guess I'd only 
googled it.  (Thanks also to Mikael.)


> > My first question is:  what's with the weird $vcs_info_msg_#_ 
> > variable names? (Why not an array?)
> 
> Those variables are exported (there was a reason for it, I don't 
> remember what it was exactly). And you can't export arrays.

Ah, okay.  So... why the trailing underscore?  Not a huge deal, just 
curious.


> > But, beyond that, my big question is: Is there a way to access the 
> > vcs_comm variable that's sprinkled throughout the VCS_Info functions 
> 
> You shouldn't.
> That's an associative array to allow bidirectional communication 
> between various parts of vcs_info. If you want to know some internals, 
> I could explain them, but for *using* vcs_info, you do not need to 
> know anything about that particular variable.

Ah.  I misinterpreted the '_comm' as 'common', not 'communication'.  I 
hadn't really delved too deeply yet, but it looked like that var was 
updated in a few places that were grabbing items I wanted to examine.


> > directory?  My guess is that the easiest thing for me to do would be 
> > to simply remove the 'local -Ax vcs_comm' line in vcs_info, but 
> > everything else is so well-organized that I figured I must just be 
> > missing some way to get that variable exported.
> 
> What do you need that variable for? Maybe if you'd explain what you want
> to do, I'd have a suggestion.

(idem)


> > The most helpful page so far was Frank Terbeck's prompt_ft_setup 
> > page[1].  Otherwise I'd've had to have read even more of the code to 
> > figure out the various
> >
> > zstyle ':vcs_info:*' actionformats ''
> > zstyle ':vcs_info:*' formats ''
> > zstyle ':vcs_info:(sv[nk]|bzr):*' branchformat
> >
> > tricks that are available.
> >
> > I already do a bunch of stuff in my pre_cmd and pre_exec functions, and 
> > I'd really like to just add some things to my prompt conditioned on 
> > whether (for example) the current git repo is in a rebase, and maybe a 
> > shortened version of the branch name.  So, is there a way to get the 
> > info out of vcs_info?
> 
> Yes, there is.
> The "shortened" make it a little trickier, though. In currently 
> released code (4.3.7), you can make one format to just be "%b" and 
> change the corresponding variable after calling vcs_info your precmd 
> function.
> 
> Vcs_info in CVS has hooks. The manual explains them in some detail and 
> gives some simpler examples. You can use a "set-message" hook to get 
> full control over what will be inserted for the branch-name. That is 
> probably what you want.
> 

Thanks for the pointers.  I saw the hook stuff in the git repo, but I 
think I'm going to do something like your format suggestion: just make 
the various formats easily-splitable, and parse out what I want.

The two things I want are abbreviated git branch names (not sure what 
I'll decide on how to abbreviate), and to modify my entire prompt when 
in a git rebase (as a big visual reminder to myself).

Both of those would be easy-peasy if I had some kind of data structure 
storing the parsed VCS data (rather than a formatted string), hence the 
initial email.

-- 
Thanks,
Ben

Re: Use of vcs_info

[Frank Terbeck]

Benjamin R. Haskell wrote:
> On Mon, 22 Mar 2010, Frank Terbeck wrote:
>> Benjamin R. Haskell wrote:
[...]
>> > My first question is:  what's with the weird $vcs_info_msg_#_ 
>> > variable names? (Why not an array?)
>> 
>> Those variables are exported (there was a reason for it, I don't 
>> remember what it was exactly). And you can't export arrays.
>
> Ah, okay.  So... why the trailing underscore?  Not a huge deal, just 
> curious.

At the time I was writing it, I thought it was a really good idea. :)
My idea was to show that something controls that variable, much like
compsys usually controls variables named _* (like `_comps[]').

[...]
> Ah.  I misinterpreted the '_comm' as 'common', not 'communication'.  I 
> hadn't really delved too deeply yet, but it looked like that var was 
> updated in a few places that were grabbing items I wanted to examine.

It's mostly used for carrying over information from the detection
mechanisms to the actual information-retrieval functions. At first there
was only `$vcs', but at some point it began to be clear that I needed
more information to be carried over.


[...]
>> > shortened version of the branch name.  So, is there a way to get the 
>> > info out of vcs_info?
>> 
>> Yes, there is.
>> The "shortened" make it a little trickier, though. In currently 
>> released code (4.3.7), you can make one format to just be "%b" and 

                  ^- This should have been 4.3.10...

>> change the corresponding variable after calling vcs_info your precmd 
>> function.
>> 
>> Vcs_info in CVS has hooks. The manual explains them in some detail and 
>> gives some simpler examples. You can use a "set-message" hook to get 
>> full control over what will be inserted for the branch-name. That is 
>> probably what you want.
>> 
>
> Thanks for the pointers.  I saw the hook stuff in the git repo, but I 
> think I'm going to do something like your format suggestion: just make 
> the various formats easily-splitable, and parse out what I want.
>
> The two things I want are abbreviated git branch names (not sure what 
> I'll decide on how to abbreviate), and to modify my entire prompt when 
> in a git rebase (as a big visual reminder to myself).
>
> Both of those would be easy-peasy if I had some kind of data structure 
> storing the parsed VCS data (rather than a formatted string), hence the 
> initial email.

With hooks you could do something like this:

# Say you only want to set a hook for the hg, git and bzr backends:
zstyle ’:vcs_info:(bzr|git|hg)+set-message:*’ hooks treatbranch

# Now define the appropriate function:
function +vi-treatbranch() {
    # There's an associative array `hook_com[]' which is used for
    # communication between vcs_info and its hooks. The relevant
    # keys for each hook (if any) are described in the manual.
    # Here, we need `branch'. There is also `branch_orig' which is
    # a copy of branch, so we always have the original value of
    # branch in case we're changing the value of the branch key.
    # That is needed because `set-message' is run for every format
    # variable that is being set (like $vcs_info_msg_0_ and
    # $vcs_info_msg_1_).

    # See below for what this is about:
    [[ ${hook_com[brh-branch-treated] == '1' ]] && return 0

    # Say, you're calling your branches `brh/*' and you want the
    # "brh" prefix to be gone and only the first five characters of
    # the remainder.

    hook_com[branch]=${${hook_com[branch]}/(#s)brh/}
    (( ${#hook_com[branch]} > 5 )) &&
        hook_com[branch]=${${hook_com[branch]}[1,5]}

    # Now, if you're using a lot of formats and don't want this to
    # run each time, you can just insert something into hook_com,
    # that is not used by vcs_info itself, like this:
    hook_com[brh-branch-treated]=1
    return 0
}

I didn't test it, but something like that can do the trick.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925