From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20487 invoked from network); 14 Mar 2003 11:54:41 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 14 Mar 2003 11:54:41 -0000 Received: (qmail 11041 invoked by alias); 14 Mar 2003 11:54:35 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 18353 Received: (qmail 11034 invoked from network); 14 Mar 2003 11:54:35 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 14 Mar 2003 11:54:34 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [212.125.75.4] by sunsite.dk (MessageWall 1.0.8) with SMTP; 14 Mar 2003 11:54:34 -0000 Received: (qmail 7761 invoked from network); 14 Mar 2003 11:54:33 -0000 Received: from iris.logica.co.uk (158.234.9.163) by server-23.tower-1.messagelabs.com with SMTP; 14 Mar 2003 11:54:33 -0000 Received: from finches.logica.co.uk ([158.234.142.11]) by iris.logica.co.uk (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA06259 for ; Fri, 14 Mar 2003 11:54:33 GMT X-Authentication-Warning: iris.logica.co.uk: Host [158.234.142.11] claimed to be finches.logica.co.uk Received: from finches.logica.co.uk (localhost [127.0.0.1]) by finches.logica.co.uk (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id h2EBwI808970 for ; Fri, 14 Mar 2003 12:58:19 +0100 X-VirusChecked: Checked In-reply-to: <28975.1047637814@csr.com> From: Oliver Kiddle References: <28975.1047637814@csr.com> To: zsh-workers@sunsite.dk Subject: Re: Completion and command versions Date: Fri, 14 Mar 2003 12:58:18 +0100 Message-ID: <8968.1047643098@finches.logica.co.uk> 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