From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13140 invoked from network); 27 Jul 2000 13:21:27 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 27 Jul 2000 13:21:27 -0000 Received: (qmail 13756 invoked by alias); 27 Jul 2000 13:21:10 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 3342 Received: (qmail 13749 invoked from network); 27 Jul 2000 13:21:09 -0000 Date: Thu, 27 Jul 2000 15:21:07 +0200 (MET DST) Message-Id: <200007271321.PAA21840@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-users@sunsite.auc.dk In-reply-to: Matthias Kopfermann's message of Thu, 27 Jul 2000 14:42:05 +0200 Subject: Re: how can one let completion work *inside* zsh scripts? Matthias Kopfermann wrote: > > To zsh-workers (and everyone else interested): hm, is this becoming > > FAQish enough to make is simplify it? For example we could allow > > compcontext to be set to `foo()' to make it just call function > > `foo'. And we could allow it to be set to an array and then make > > completion offer its elements as possible completions. > I am for it ! The easier the better. At least normally I > tend to think that way. I'll add something like this (mostly because it doesn't cost us anything if compcontext isn't set). But first some questions: _arguments and friends allow `(( 1\:foo 2\:bar ))' to generate the matches `1' and `2' and make them be shown with descriptions `foo' and `bar', respectively. That might be nice to have here, too, think. But stuffing them all in one string isn't needed here. Hm. Maybe if all string contain an (non-backslash-quoted) colon, take everything before them as the matches and the stuff after them as the descriptions. People would then have to remember to quote colons when setting compcontext from something automatically generated such as filenames (using globbing). And then we should allow the calling function to register a description string for the whole set of matches (the things one gets by setting the format style). But that almost suggest (at least to me, striving for consistency) to put everything into a string of the form `:', where is as in _arguments, i.e.: {...} = evaluate `...' (1 2) = complete `1' and `2' (( 1\:foo 2\:bar )) = complete `1' and `2' and describe them as `foo' and `bar' in the list Hm, is this going too far? Or should we use the array-based solution and allow to give the description with another parameter? Or should we just support compcontext-as-array without (a) description(s) (and the `func()' form) and let user's use functions if they need descriptions? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de