From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13623 invoked from network); 10 Jan 2003 08:11:00 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 10 Jan 2003 08:11:00 -0000 Received: (qmail 10162 invoked by alias); 10 Jan 2003 08:10:54 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 18071 Received: (qmail 10155 invoked from network); 10 Jan 2003 08:10:53 -0000 From: Borzenkov Andrey To: "'Oliver Kiddle'" , zsh-workers@sunsite.dk Subject: RE: Passsing descriptions down in completion functions Date: Fri, 10 Jan 2003 11:10:44 +0300 Message-ID: <6134254DE87BD411908B00A0C99B044F03A0B5D5@MOWD019A> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-reply-to: <503.1042132191@finches.logica.co.uk> > On 9 Jan, you wrote: > > > > Well, I started to look into these functions and immediately hit = some > > problems: > > > > AIX/Type/_object_classes: > > > > _wanted objectclasses expl 'object class' \ > > _files -W ${ODMDIR:-/etc/objrepos} -g '^*.vc' > > > > Here is just no place where I could stuff the magic "-". Granted, = this > one > > does not pass arguments it receives but in general I do not see why = it > > should not do it. >=20 > I think you can put the "-" on the end of the line like this: > _wanted ... \ > _files -W ${ODMDIR:-/etc/objrepos} -g '^*.vc' "$@" - >=20 But you cannot know in advance how _arbitrary_ completion function = would react to stray "-" > > Base/Utility/_sub_commands > > > > if [[ CURRENT -eq 2 ]]; then > > _wanted commands expl command compadd "$@" > > else > > _message 'no more arguments' > > fi > > > > almost the same problem. In this case arguments contain both = description > and > > matches so I have no way to stuff "-" in between. >=20 > That's a slightly unusual case because any matches passed to > _sub_commands could be thought of as not being arguments to compadd = to > be passed on in the traditional sense. It is probably best handled by > passing a "-" in the calling function. >=20 Snowball effect :( > I agree that this isn't particularly ideal though. I remember Sven > saying something about rethinking the way compadd options are passed > but I was mostly thinking in terms of suffixes and not descriptions. > It'd be wise to think in terms of all the compadd options and how = they > are passed around in coming up with a good solution. >=20 Yep. I was thinking mostly not about special way to pass arguments = (unless absolutely needed) but rather about documented discipline. = Approximately - every completion function (i.e. function that generates matches, = directly or indirectly) must accept all compadd options, must not change their semantic and must pass them down to any other function it calls (except = as noted below). It limits options, available for private use, but in = general I hope usage of special options should not be widespread. Or we can = reserve a special option for quoting, like gcc does it _foo ...-normal compadd options... -X -my-option -X my-option-argument ...-normal compadd options... (-X is taken, I know). This is relatively easy to do assuming all = functions are using zparseopts - low level completion utilities _never_ modify passed options, it is = simply not their business. > A variant of your _all_labels suggestion is perhaps not a bad idea. = I'd > want to be able to override any passed descriptions in some cases. > then do it in completion function that actually needs it (I presume it = is actually a minority). Replace passed arguments with your own. This = needs some utility, we just need to think about the best way to do it. = Probably as an option to zparseopts or something like zmergeopts [options] current new where options would be "override", "preserve" and probably more. This allows such functions as _wanted (or _all_labels) to extract = options from passed command and possibly merge them with generated description = if needed. Extracting options may need some extra utility as well. Any comments? -andrey