Re: Use of vcs_info

[Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx>]

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