From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9463 invoked from network); 14 Mar 2000 19:40:01 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 14 Mar 2000 19:40:01 -0000 Received: (qmail 29194 invoked by alias); 14 Mar 2000 19:39:55 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10142 Received: (qmail 29182 invoked from network); 14 Mar 2000 19:39:55 -0000 Message-ID: <38CE957C.679D7F93@u.genie.co.uk> Date: Tue, 14 Mar 2000 19:39:40 +0000 From: Oliver Kiddle X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Zsh workers Subject: Re: PATCH: Re: Saving the zle display stuff References: <200003141459.PAA09515@beta.informatik.hu-berlin.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sven Wischnowsky wrote: > > Oliver Kiddle wrote: > > I seem to have some fairly long option exclusion lists in some of my > > completions so it might also be worth thinking if there are any better > > ways of doing the completion when there are separate forms of the > > command. I experimented with a few things like using two calls to > > _arguments without much success. > > Yep. Any suggestions? ;-) I've got some ideas but I'm not sure how workable they would be. First, I suppose we would need some syntax to divide the arguments to _arguments into separate groups. At a simple level, you could say that each group defined the options for a separate form of the command and use something like '--' to separate the groups. The main additional functionality that this would offer over the current situation is that you could define separate non-option arguments (*:... or n:...) for each group. Many commands will have some options which are common to their different forms though so a syntax which allows groups to be labelled and excluded as a whole would avoid any repetition in the arguments. So for example, you might have: _arguments -C \ '(form2 form3)form1:' \ '-e:files:_files' \ '(form1 form3)form2:' \ '(-f)-a: ... '-e:...:_users' \ '(-a -r)-f: ... '(common form1 form2)form3:' \ '-l: ... '*:users:_users' \ '(form3)common:' \ '(-f)-r: ... '*:files:_files' Here, I have used the labels form1, form2, form3 and common. Hopefully the syntax is clear; there may be better ways of representing it. Here the command would have 3 forms. The first two have separate parameters which are defined in their respective groups (form1 has the -e option and form2 has a -a, -f and a different -e option). They both share the arguments defined in the common group (a -r option and files being completed ordinarily). The third form of the command just has a -l option - it doesn't use anything from the common group. In addition it completes users ordinarily. The -e option raises one issue because there are two different definitions - in form1 and form2. Initially, both users and files would be completed after -e but if at any point a -a or -f option was used, only users (form2) would be completed. There would be a similar situation initially for the '*:... arguments. Anything which excluded (*) would exclude both (would there be a problem with this?). In summary, this is grouping the arguments and using common exclusion lists for the groups and allowing the groups to exclude other whole groups. You could easily expand the above to have longer exclusion lists and use the current syntax (although you couldn't deal with two -e and two * definitions). Does this make sense? Is this suggestion far too complicated? Finally, thanks Sven for that solution for command-completion taking ages problem. That works very nicely thanks. Oliver Kiddle