Re: Submitting vcs_info function

[Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx>]

Peter Stephenson <pws@xxxxxxx>:
> On Wed, 17 Sep 2008 22:18:59 +0200
> Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx> wrote:
> > I've been working on this for quite some time now. vcs_info is a
> > function that is able to get information about directories under
> > version control. That information can be used in prompts, for example.
> > 
> > I am submitting this for inclusion in the next zsh release - if the
> > developers deem it to be worthy. I think Functions/Misc/vcs_info would
> > be a proper place.
> 
> Thanks.  This will be useful.
> 
> I'd like to suggest a slightly different interface (internally, this
> wouldn't affect the use).  I think it would be best if it lived in
> Functions/VCS_Info with a single central function in one file, backends in

Ah, okay. I agree this makes sense. The current layout is largely due
to convenience to be able to point people at one file, that can
install.

I'll rework this a little and provide a tarball then.

> VCS_INFO_BACKEND_<backend>, and any utility functions in other files
> (though small ones could be in the main function file).  Then you don't
> need to load a backend you're not using and the central function can query
> backends by searching the function path for files of that name (the sort of
> thing that's easy in zsh) and autoloading the function in question so you
> wouldn't need an explicit list. 

Completely agreed.

> I'd suggest that functions for each backend be done as arguments
> "VCS_INFO_BACKEND_<backend> get_data", but it could equally be
> something like VCS_INFO_backend_<backend>_get_data or anything
> explicit enough that wouldn't get confused with another backend.

I think
    VCS_INFO_get_data_<backend>
and VCS_INFO_detect_<backend>
should be explicit enough. Wouldn't it?

> I'd also suggest it would be more useful to enable, rather than disable,
> backends.  I tend to know which archiving systems I'm using and it's not
> particular convenient to have to disable a whole series I may never even
> have heard of, and which may well be extended in future versions so is a
> moving target.  However, there's nothing to stop you having both with
> "enable" taking preference.

I think I'll do this:
    + enable is a list style.
    + disable list style (no change here).

If one entry in 'enable' equals "all", all backends are enabled except
for the ones in 'disable'.

If no entry in 'enable' equals "all", 'disable' is ignored and only
system listed in 'enable' are loaded.

I don't know if the default for 'enable' should be:
    ( "all" )
or something "reasonable" (I know, I know, subjectivity...):
    ( "git" "cvs" "svn" "hg" )

> It should be possible to use the new prompt colouring features in the
> version that goes into the archive (%F{red}...%f), so explicit escapes can
> be avoided.

Yeah, and the documentation should use those new expansions. I didn't
look into those yet, I must admit. :)

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