gmane.comp.shells.zsh.user

Frank Terbeck | 17 Sep 22:18

Submitting vcs_info function

Hi list,

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.

I short example of how a vcs_info enabled prompt can look like can be
found here:
 <http://bewatermyfriend.org/posts/2008/09-17.13-43-05-computer.html>

I am attaching the vcs_info file to this mail. And I will post a
follow-up message, that will contain a documentation patch against
Doc/Zsh/contrib.yo.

If people want to give this a try, here is what the doc patch
contains:

[snip]
ZSHCONTRIB(1)                                                    ZSHCONTRIB(1)

NAME
       zshcontrib - user contributions to zsh
[...]

UTILITIES
[...]

(Continue reading)

Frank Terbeck | 17 Sep 22:32

Re: Submitting vcs_info function

Frank Terbeck <ft <at> bewatermyfriend.org>:
[...]
> I am attaching the vcs_info file to this mail. And I will post a
> follow-up message, that will contain a documentation patch against
> Doc/Zsh/contrib.yo.

Here is the doc patch.
Note that this is my first stab at yodl documentation, so I'm not
entirely sure if I did it like it's supposed to be. The manpage
renders the way I would expect it to, though.

Index: Doc/Zsh/contrib.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/contrib.yo,v
retrieving revision 1.83
diff -u -r1.83 contrib.yo
--- Doc/Zsh/contrib.yo	24 Jun 2008 16:09:28 -0000	1.83
+++ Doc/Zsh/contrib.yo	17 Sep 2008 20:04:22 -0000
@@ -316,6 +316,321 @@
 )
 enditem()

+subsect(Gathering information from version control systems)
+cindex(versioncontrol utility)
+
+In a lot of cases, it is nice to automatically retrieve information from
+version control systems (VCSs), such as subversion, CVS or git, to be able
+to provide it to the user; possibly in the user's prompt. So that you can
+instantly tell on which branch you are currently on,  for example.
+

(Continue reading)

Clint Adams | 21 Sep 11:11

Re: Submitting vcs_info function

On Wed, Sep 17, 2008 at 10:32:42PM +0200, Frank Terbeck wrote:
> +If you plan to use the information from var(vcs_info) in your prompt (which
> +is its primary use), you need to enable the tt(PROMPT_SUBST) option.

I don't think that this claim is accurate.

Index: Functions/Prompts/prompt_clint_setup
===================================================================
RCS file: /cvsroot/zsh/zsh/Functions/Prompts/prompt_clint_setup,v
retrieving revision 1.9
diff -u -r1.9 prompt_clint_setup
--- Functions/Prompts/prompt_clint_setup	17 May 2008 22:42:17 -0000	1.9
+++ Functions/Prompts/prompt_clint_setup	21 Sep 2008 09:07:53 -0000
@@ -15,6 +15,8 @@
   local -A pc
   local p_date p_tty p_plat p_ver p_userpwd p_apm p_shlvlhist p_rc p_end p_win

+  autoload -Uz vcs_info
+
   pcc[1]=${1:-'red'}
   pcc[2]=${2:-'cyan'}
   pcc[3]=${3:-'green'}
@@ -36,7 +38,7 @@
   [[ -n "$WINDOW" ]] && p_win="$pc['\(']%F{$pcc[4]}$WINDOW$pc['\)']"

   p_userpwd="$pc['<']%F{$pcc[3]}%n@%m$p_win%F{$pcc[5]}:%F{$pcc[4]}%~$pc['>']"
-  p_git="%(2v.-%U%2v%u-.)"
+  p_vcs="%(2v.%U%2v%u.)"

   p_shlvlhist="%fzsh%(2L./$SHLVL.) %B%h%b "

(Continue reading)

Phil Pennock | 21 Sep 11:39

Re: Submitting vcs_info function

On 2008-09-21 at 09:11 +0000, Clint Adams wrote:
> On Wed, Sep 17, 2008 at 10:32:42PM +0200, Frank Terbeck wrote:
> > +If you plan to use the information from var(vcs_info) in your prompt (which
> > +is its primary use), you need to enable the tt(PROMPT_SUBST) option.
> 
> I don't think that this claim is accurate.

Ditto.  Although it would be nice if vcs_info made all the different
variables available in a $Z_VCS hash or somesuch, so that I didn't need
to zstyle from my prompt.

FWIW, here's a lightly modified version of the prompt I'm using now,
built up over years, originally with help from zefram@ and then later
with some attention to Bart's setup and generally munged about.  I
finally updated it to use the new colour codes, since the vcs_info stuff
led to me using more elements of $psvar, deciding to add %(V..)
conditional to check if set and then seeing that CVS had already done
just that.  Convenient.  :)

Reports screen WINDOW, SHLVL, previous command exit status (including
signal name if sig-exit), count of backgrounded jobs, repository
information plus the usual bits.  Has some automatic screen titling
stuff in the prompt too.

----------------------------8< cut here >8------------------------------
# Phil's prompt setup for zsh
#
# $HeadURL:
https://svn.spodhuis.org/ksvn/spodhuis-tools/zsh/site-functions/prompt_pdp-vcs_setup $
# $Id: prompt_pdp-vcs_setup 239 2008-09-20 21:37:30Z xxx <at> SPODHUIS.ORG $

(Continue reading)

Phil Pennock | 21 Sep 12:00

Re: Submitting vcs_info function

On 2008-09-21 at 02:39 -0700, Phil Pennock wrote:
> Reports screen WINDOW, SHLVL, previous command exit status (including
> signal name if sig-exit), count of backgrounded jobs, repository
> information plus the usual bits.  Has some automatic screen titling
> stuff in the prompt too.

Anyone have any recommendations for using zstyle with prompts?

I've gone for:
  :prompt:<theme>:<$TERM>:<colour|mono>
in the absence of any better ideas.  This removes a TODO from the file,
to move the employer logic out into a style.

I sometimes make an effort to sync my configs a bit between the setups
and it's useful to have the employer in my prompt; or at least, at
3.30am after the pager goes off and before coffee, I tend to think so.
Besides, I use a really-cheesy multi-coloured tag reminiscent of my
employer's logo, which makes people groan.  :)

----------------------------8< cut here >8------------------------------
--- posted-prompt	Sun Sep 21 02:55:21 2008
+++ prompt_pdp-vcs_setup	Sun Sep 21 02:52:38 2008
@@ -1,7 +1,7 @@
 # Phil's prompt setup for zsh
 #
 # $HeadURL:
https://svn.spodhuis.org/ksvn/spodhuis-tools/zsh/site-functions/prompt_pdp-vcs_setup $
-# $Id: prompt_pdp-vcs_setup 239 2008-09-20 21:37:30Z xxx <at> SPODHUIS.ORG $
+# $Id: prompt_pdp-vcs_setup 240 2008-09-21 09:52:38Z xxx <at> SPODHUIS.ORG $
 #

(Continue reading)

Frank Terbeck | 21 Sep 12:23

Re: Submitting vcs_info function

Clint Adams <clint <at> zsh.org>:
> On Wed, Sep 17, 2008 at 10:32:42PM +0200, Frank Terbeck wrote:
> > +If you plan to use the information from var(vcs_info) in your prompt (which
> > +is its primary use), you need to enable the tt(PROMPT_SUBST) option.
> 
> I don't think that this claim is accurate.

Hm, true. How about 'Unless you dynamically build your prompt in
precmd(), you will need PROMPT_SUBST enabled.'?

Or: 'Depending on the way you are building your prompt you may need
PROMPT_SUBST enabled.'

Or something completely different (like dropping that sentence
altogether)?

Regards, Frank

Clint Adams | 22 Sep 19:17

Re: Submitting vcs_info function

On Sun, Sep 21, 2008 at 12:23:06PM +0200, Frank Terbeck wrote:
> Or something completely different (like dropping that sentence
> altogether)?

I like that one.

Index: Doc/Zsh/contrib.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/contrib.yo,v
retrieving revision 1.87
diff -u -r1.87 contrib.yo
--- Doc/Zsh/contrib.yo	22 Sep 2008 16:57:49 -0000	1.87
+++ Doc/Zsh/contrib.yo	22 Sep 2008 17:16:06 -0000
@@ -347,9 +347,6 @@

 example(autoload -Uz vcs_info)

-If you plan to use the information from var(vcs_info) in your prompt (which
-is its primary use), you need to enable the tt(PROMPT_SUBST) option.
-
 It can be used in any existing prompt, because it does not require any
 tt($psvar) entries to be left available.

Phil Pennock | 18 Sep 01:34

Re: Submitting vcs_info function

On 2008-09-17 at 22:18 +0200, Frank Terbeck wrote:
>               All functions named VCS_INFO_* are for internal use only.
> 
> 
>        Variable description
> 
>               ${VCS_INFO_message_N_} (Note the trailing underscore)

It's a rather confusing distinction that functions named VCS_INFO_* are
internal but variables named VCS_INFO_* are how you get access to the
results.

> Comments welcome. :)

In general, this looks great and I intend to use it.

> VCS_INFO_svn_get_data () { # {{{
>     setopt localoptions noksharrays extendedglob
>     local svnbase svnbranch
>     local -a svninfo
> 
>     svnbase="."
>     while [[ -d "${svnbase}/../.svn" ]]; do
>         svnbase="${svnbase}/.."
>     done

However, this is a deal-breaker for me at present, since it doesn't
handle svn:externals so will chase up to the top-level.  For many cases,
for personal development, on my server, that means getting up to my
home directory svn repo, as various other repositories, including some

(Continue reading)

Frank Terbeck | 18 Sep 01:58

Re: Submitting vcs_info function

Phil Pennock <zsh-workers+phil.pennock <at> spodhuis.org>:
> On 2008-09-17 at 22:18 +0200, Frank Terbeck wrote:
> >               All functions named VCS_INFO_* are for internal use only.
[...]
> >               ${VCS_INFO_message_N_} (Note the trailing underscore)
> 
> It's a rather confusing distinction that functions named VCS_INFO_* are
> internal but variables named VCS_INFO_* are how you get access to the
> results.

Hm, good point. I think I'll rename the variables to vcs_info_msg_N_.

> > Comments welcome. :)
> 
> In general, this looks great and I intend to use it.
> 
> > VCS_INFO_svn_get_data () { # {{{
> >     setopt localoptions noksharrays extendedglob
> >     local svnbase svnbranch
> >     local -a svninfo
> > 
> >     svnbase="."
> >     while [[ -d "${svnbase}/../.svn" ]]; do
> >         svnbase="${svnbase}/.."
> >     done
> 
> However, this is a deal-breaker for me at present, since it doesn't
> handle svn:externals so will chase up to the top-level.  For many cases,

Yes, that's quite right.

(Continue reading)

Phil Pennock | 18 Sep 02:28

Re: Submitting vcs_info function

On 2008-09-18 at 01:58 +0200, Frank Terbeck wrote:
> Well, how deep are your typical repositories? Do they go a lot
> further then, say, five levels?

Probably not, but stopping at the UUID change is fine.  I think that I
dealt with all of my stated problems, except the repeated invocation of
svn info, in my supplied replacement.  :)

> > Also, I don't believe that "svn info" makes any guarantees about output
> > ordering.
> 
> That would be unfortunate. I wouldn't mind, if there would be another
> more machine-friendly way to extract the information... But that would
> have to be done by a subversion-dev.

*cough*  Define machine-friendly?  The canonical method supported by
Subversion is to use XML.

svn info --xml

I'm not inclined to parse that in zsh.

-Phil

Frank Terbeck | 18 Sep 02:34

Re: Submitting vcs_info function

Phil Pennock <zsh-workers+phil.pennock <at> spodhuis.org>:
> On 2008-09-18 at 01:58 +0200, Frank Terbeck wrote:
[...]
> > > Also, I don't believe that "svn info" makes any guarantees about output
> > > ordering.
> > 
> > That would be unfortunate. I wouldn't mind, if there would be another
> > more machine-friendly way to extract the information... But that would
> > have to be done by a subversion-dev.
> 
> *cough*  Define machine-friendly?  The canonical method supported by
> Subversion is to use XML.
> 
> svn info --xml
> 
> I'm not inclined to parse that in zsh.

Well, me neither. :)
We could however, do what we do now, and additionally introduce a
'use-perl' style, that uses perl with an appropriate module, that
parses the xml output. Unless someone writes an interface to some xml
library for zsh. :)

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

(Continue reading)

Peter Stephenson | 18 Sep 12:20

Re: Submitting vcs_info function

On Wed, 17 Sep 2008 22:18:59 +0200
Frank Terbeck <ft <at> bewatermyfriend.org> 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
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.  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'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

(Continue reading)

Frank Terbeck | 18 Sep 18:52

Re: Submitting vcs_info function

Peter Stephenson <pws <at> csr.com>:
> On Wed, 17 Sep 2008 22:18:59 +0200
> Frank Terbeck <ft <at> bewatermyfriend.org> 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.

(Continue reading)

Peter Stephenson | 18 Sep 19:00

Re: Submitting vcs_info function

Frank Terbeck wrote:
> > 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?

Yes, it's basically what I said, except I wasn't actually looking at
what it already does, so it doesn't need to change.

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

I've never heard of one of those, don't use one of those at all, and
rarely use one of the remaining two, so perhaps "all" is the only
sensible default.  The documenation should probably recommand setting it
explicitly.

--

-- 
Peter Stephenson <pws <at> csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

(Continue reading)

Frank Terbeck | 18 Sep 19:04

Re: Submitting vcs_info function

Peter Stephenson <pws <at> csr.com>:
> > I don't know if the default for 'enable' should be:
> >     ( "all" )
> > or something "reasonable" (I know, I know, subjectivity...):
> >     ( "git" "cvs" "svn" "hg" )
> 
> I've never heard of one of those, don't use one of those at all, and
> rarely use one of the remaining two, so perhaps "all" is the only
> sensible default.  The documenation should probably recommand setting it
> explicitly.

Okay. Will do that.

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

Frank Terbeck | 19 Sep 11:34

Re: Submitting vcs_info function

Peter Stephenson <pws <at> csr.com>:
[...]
> I've never heard of one of those, don't use one of those at all, and
> rarely use one of the remaining two, so perhaps "all" is the only
> sensible default.  The documenation should probably recommand setting it
> explicitly.

Here it is. <http://ft.bewatermyfriend.org/comp/vcsinfo.tar.gz>

[snip]
% tar tf vcsinfo.tar.gz
VCS_Info/
VCS_Info/Backends/
VCS_Info/Backends/VCS_INFO_detect_bzr
VCS_Info/Backends/VCS_INFO_detect_cdv
VCS_Info/Backends/VCS_INFO_detect_cvs
VCS_Info/Backends/VCS_INFO_detect_darcs
VCS_Info/Backends/VCS_INFO_detect_git
VCS_Info/Backends/VCS_INFO_detect_hg
VCS_Info/Backends/VCS_INFO_detect_mtn
VCS_Info/Backends/VCS_INFO_detect_svk
VCS_Info/Backends/VCS_INFO_detect_svn
VCS_Info/Backends/VCS_INFO_detect_tla
VCS_Info/Backends/VCS_INFO_get_data_bzr
VCS_Info/Backends/VCS_INFO_get_data_cdv
VCS_Info/Backends/VCS_INFO_get_data_cvs
VCS_Info/Backends/VCS_INFO_get_data_darcs
VCS_Info/Backends/VCS_INFO_get_data_git
VCS_Info/Backends/VCS_INFO_get_data_hg
VCS_Info/Backends/VCS_INFO_get_data_mtn

(Continue reading)

Frank Terbeck | 19 Sep 11:41

Re: Submitting vcs_info function

Frank Terbeck <ft <at> bewatermyfriend.org>:
[...]
> I think I incorporated all changes due to comments by Phil and Peter.

The default $fpath will need some adjustment, I guess. I'm not sure
how that's done, though.

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

Peter Stephenson | 19 Sep 11:50

Re: Submitting vcs_info function

Frank Terbeck wrote:
> Frank Terbeck <ft <at> bewatermyfriend.org>:
> [...]
> > I think I incorporated all changes due to comments by Phil and Peter.
> 
> The default $fpath will need some adjustment, I guess. I'm not sure
> how that's done, though.

That's the functions line in Src/zsh.mdd which propagates to
config.modules and thence to the FPATH_* definitions.  I'll try to
remember to change it when I get around to this.  I'm a bit busy at the
moment.

pws

Frank Terbeck | 19 Sep 11:54

Re: Submitting vcs_info function

Peter Stephenson <pws <at> csr.com>:
> Frank Terbeck wrote:
> > The default $fpath will need some adjustment, I guess. I'm not sure
> > how that's done, though.
> 
> That's the functions line in Src/zsh.mdd which propagates to
> config.modules and thence to the FPATH_* definitions.  I'll try to
> remember to change it when I get around to this.  I'm a bit busy at the
> moment.

So this should be enough?

Index: zsh.mdd
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/zsh.mdd,v
retrieving revision 1.17
diff -u -r1.17 zsh.mdd
--- zsh.mdd	13 Mar 2008 11:11:04 -0000	1.17
+++ zsh.mdd	19 Sep 2008 09:54:23 -0000
@@ -2,7 +2,7 @@
 link=static
 load=yes
 # load=static should replace use of alwayslink
-functions='Functions/Exceptions/* Functions/Misc/* Functions/MIME/* Functions/Prompts/*'
+functions='Functions/Exceptions/* Functions/Misc/* Functions/MIME/* Functions/Prompts/*
Functions/VCS_Info/* Functions/VCS_Info/Backends/*'

 nozshdep=1
 alwayslink=1

(Continue reading)

Frank Terbeck | 19 Sep 13:51

Re: Submitting vcs_info function

Frank Terbeck <ft <at> bewatermyfriend.org>:
> Here it is. <http://ft.bewatermyfriend.org/comp/vcsinfo.tar.gz>

*sigh*
A mistake made it into the tarball. I just updated it.

If you downloaded the tarball before:
% date -u
Fri Sep 19 11:50:45 UTC 2008

You should get the updated one. Sorry about that.

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

Peter Stephenson | 19 Sep 15:02

Re: Submitting vcs_info function

On Fri, 19 Sep 2008 11:34:49 +0200
Frank Terbeck <ft <at> bewatermyfriend.org> wrote:
> Here it is. <http://ft.bewatermyfriend.org/comp/vcsinfo.tar.gz>

I've committed the basics, with some work on the documentation.  Even if
it's not perfect it shouldn't interfere with the result of the shell.
Consequently apart from making the documentation looking a bit more like
the rest of the documentation (I didn't look too much at the content) I
haven't done much checking of what's going on.

You may need to "make prep" to get config.modules updated to include the
functions to install.

--

-- 
Peter Stephenson <pws <at> csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Peter Stephenson | 19 Sep 15:09

Re: Submitting vcs_info function

On Fri, 19 Sep 2008 14:02:29 +0100
Peter Stephenson <pws <at> csr.com> wrote:
> You may need to "make prep" to get config.modules updated to include the
> functions to install.

Ackshly, it seems you need to run "./config.status --recheck;
sh ./config.modules.sh".  This is only for building after a cvs update, not
from scratch.

--

-- 
Peter Stephenson <pws <at> csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Frank Terbeck | 19 Sep 15:36

Re: Submitting vcs_info function

Peter Stephenson <pws <at> csr.com>:
> On Fri, 19 Sep 2008 14:02:29 +0100
> Peter Stephenson <pws <at> csr.com> wrote:
> > You may need to "make prep" to get config.modules updated to include the
> > functions to install.
> 
> Ackshly, it seems you need to run "./config.status --recheck;
> sh ./config.modules.sh".  This is only for building after a cvs update, not
> from scratch.

I built the current cvs HEAD, and it works for me.

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

Frank Terbeck | 19 Sep 15:34

Re: Submitting vcs_info function

Peter Stephenson <pws <at> csr.com>:
> On Fri, 19 Sep 2008 11:34:49 +0200
> Frank Terbeck <ft <at> bewatermyfriend.org> wrote:
> > Here it is. <http://ft.bewatermyfriend.org/comp/vcsinfo.tar.gz>
> 
> I've committed the basics, with some work on the documentation.  Even if
> it's not perfect it shouldn't interfere with the result of the shell.
> Consequently apart from making the documentation looking a bit more like
> the rest of the documentation (I didn't look too much at the content) I
> haven't done much checking of what's going on.

Thank you.
One minor glitch in the list of styles:

Index: Doc/Zsh/contrib.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/contrib.yo,v
retrieving revision 1.84
diff -u -r1.84 contrib.yo
--- Doc/Zsh/contrib.yo	19 Sep 2008 12:58:50 -0000	1.84
+++ Doc/Zsh/contrib.yo	19 Sep 2008 13:32:31 -0000
@@ -497,8 +497,11 @@
 backend is used at all and var(vcs_info) will do nothing. If this list
 contains tt(ALL) var(vcs_info) will use all backends known to it. Only with
 tt(ALL) in tt(enable), the tt(disable) style has any effect. tt(ALL) and
-tt(NONE) are actually tested case insensitively.)
-sitem(tt(disable))(A list of VCSs, you don't want var(vcs_info) to test for
+tt(NONE) are actually tested case insensitively.
+)
+kindex(disable)

(Continue reading)

Frank Terbeck | 19 Sep 16:57

Re: Submitting vcs_info function

[moved to workers]

Frank Terbeck <ft <at> bewatermyfriend.org>:
> One minor glitch in the list of styles:

Here is another:

Index: Doc/Zsh/contrib.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/contrib.yo,v
retrieving revision 1.85
diff -u -r1.85 contrib.yo
--- Doc/Zsh/contrib.yo	19 Sep 2008 13:50:41 -0000	1.85
+++ Doc/Zsh/contrib.yo	19 Sep 2008 14:55:41 -0000
@@ -581,8 +581,10 @@
 function you want to call from tt(precmd) if you want to include up-to-date
 information in your prompt (see Variable description below). If an argument
 is given, that string will be used instead of tt(default) in the
-user-context field of the style context.)
-sitem(tt(vcs_info_lastmsg))(Outputs the last var(${vcs_info_msg_*_}) value.
+user-context field of the style context.
+)
+item(tt(vcs_info_lastmsg))(
+Outputs the last var(${vcs_info_msg_*_}) value.
 Takes into account the value of the use-prompt-escapes style in
 var(':vcs_info:formats:command:-all-'). It also only prints tt(max-exports)
 values.
@@ -591,8 +593,10 @@
 item(tt(vcs_info_printsys) [var(user-context)])(
 Prints a list of all

(Continue reading)

Wayne Davison | 21 Sep 23:24

Re: Submitting vcs_info function

On Fri, Sep 19, 2008 at 02:02:29PM +0100, Peter Stephenson wrote:
> I've committed the basics, with some work on the documentation.

There is no VCS_Info dir or vcs_info file in CVS yet.  Since it's
mentioned in the docs, that seems like an oversight.

..wayne..

Frank Terbeck | 21 Sep 23:33

Re: Submitting vcs_info function

Wayne Davison <wayned <at> users.sourceforge.net>:
> On Fri, Sep 19, 2008 at 02:02:29PM +0100, Peter Stephenson wrote:
> > I've committed the basics, with some work on the documentation.
> 
> There is no VCS_Info dir or vcs_info file in CVS yet.  Since it's
> mentioned in the docs, that seems like an oversight.

It's in CVS already:
  <http://zsh.cvs.sourceforge.net/zsh/zsh/Functions/VCS_Info/>

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

Clint Adams | 21 Sep 21:57

Re: Submitting vcs_info function

On Wed, Sep 17, 2008 at 10:18:59PM +0200, Frank Terbeck 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.

Some initial feedback is that performancewise git is great,
svn has mixed reactions, and bzr is slow as a dog, even with use-simple
on.

Maybe someone can suggest some optimizations.

Frank Terbeck | 21 Sep 22:32

Re: Submitting vcs_info function

Clint Adams <schizo <at> debian.org>:
> [...]bzr is slow as a dog, even with use-simple on.

The normal bzr backend *is* slow. It calls bzr itself twice. Which
takes about half a second on my system, at best. Agonising.

But the use-simple backend really only reads from *one* file. That
should work instantaneous, unless you're on a networked filesystem.

Are the people complaining _sure_ they enabled use-simple correctly?

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

Clint Adams | 22 Sep 08:42

Re: Submitting vcs_info function

On Sun, Sep 21, 2008 at 10:32:12PM +0200, Frank Terbeck wrote:
> Are the people complaining _sure_ they enabled use-simple correctly?

I do not have assurance of this.

Return

Return to gmane.comp.shells.zsh.user.

Advertisement

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane