From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: zsh-workers@sunsite.dk
Subject: Re: Completion and command versions
Date: Fri, 14 Mar 2003 12:58:18 +0100 [thread overview]
Message-ID: <8968.1047643098@finches.logica.co.uk> (raw)
In-Reply-To: <28975.1047637814@csr.com>
Peter wrote:
> Doug Kearns wrote:
> > Is there a policy regarding the command version that completion
> > functions should support? What about commands where there are
> > significant changes between versions?
I don't think we have any official policy. For most commands, where the
differences are little more than a few added options I just update it
to the latest version.
If an option that takes an argument is removed you could precede the
_arguments spec with \! so that it is recognised but not completed.
Where a command changes significantly, and in particular where an old
version continues to be in wide use, it can then be worth the trouble
of handling the old version.
> The standard way is using the _pick_variant function.
>
> If it's too dangerous to run the command to find out what it does, you
> probably need a style. `variant' is already use by _pick_variant,
> unfortunately --- it's not a very good name, since it doesn't give the
> variant, it gives the programme to run to pick the variant. Of course
_pick_variant is not in 4.0 so it isn't too late to change this. It
perhaps should stick with the command style but set the tag to `variant'
when looking it up.
Another issue we perhaps ought to think about is how we keep track
of what version of a command the functions have been updated to. I
notice some people have put a version number in a comment at the top
of functions which is one way. What we could do is setup a separate cvs
repository containing the output of the commands' --help (or equivalent)
outputs. I've found that diffing these is a good way of finding any
new options - assuming I still have the old program around to get it's
--help output.
Oliver
next prev parent reply other threads:[~2003-03-14 11:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-14 0:14 Doug Kearns
2003-03-14 10:30 ` Peter Stephenson
2003-03-14 11:58 ` Oliver Kiddle [this message]
2003-03-19 13:45 ` Oliver Kiddle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8968.1047643098@finches.logica.co.uk \
--to=okiddle@yahoo.co.uk \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).