Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Use of vcs_info

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]} > 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:
    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

Messages sorted by: Reverse Date, Date, Thread, Author