From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27042 invoked from network); 10 Feb 1999 16:43:33 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 Feb 1999 16:43:33 -0000 Received: (qmail 12232 invoked by alias); 10 Feb 1999 16:43:01 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5331 Received: (qmail 12224 invoked from network); 10 Feb 1999 16:42:59 -0000 Message-Id: <9902101626.AA46190@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk Subject: Re: PATCH: compadd (+ questions) In-Reply-To: "Sven Wischnowsky"'s message of "Mon, 01 Feb 1999 10:10:55 NFT." <199902010910.KAA06912@beta.informatik.hu-berlin.de> Date: Wed, 10 Feb 1999 17:26:57 +0100 From: Peter Stephenson Just some queries about the new-style completion. I'll put the more general questions first, then there are some more specific questions mainly to do with compadd. First... I was looking at new-completion-examples and wondered: 1) I suspect most people are going to use much of it as it stands, and just alter what they want. (Who the *other* people might be, I cannot imagine.) So might it be an idea to find a more general name than my-comp, and also to define widgets using main-complete for all the standard completion functions, not just expand-or-complete? And perhaps do some trickery with bindkey output to rebind any keys using the old ones to the new ones? Some way of supplying options to new-completion-examples would be good. 2) Currently, existing compctl's take precedence over any of the new style functions for given commands. That's sort of reasonable at the moment, since many of the new-style functions are examples rather than complete systems. I wonder if there's a better way of deciding this. If we implement something like 3), it might be better for the new-style ones to take precedence. 3) As far as the example functions are concerned, it might be an idea to separate them out into their own directory so they can be autoloaded or copied for autoloading. How about this: they get separated into a directory, and then some code in the main file scans that directory and decides file by file how to call defcomp. For example, the file __default might contain #defcomp --default-- files and then new-completion-examples can contain something like local d f a for d in $fpath; do for f in $d/__*(N); do read -A a <$f if [[ $a[1] = '#defcomp' ]]; then defcomp $f:t $a[2] fi done done Users can then put this directory where they want in their $fpath and add or subtract from it to get autoloading of completion functions. Also new-completion-examples can have a shorter name in its own directory. Next... I'm late replying to this, but I was just looking over the new-style completion again and had some niggling questions... I have half an eye on documentation for this new stuff, which Sven should probably have a go at first, although I think with something this involved it's good if someone other than the author makes sure they can understand it. Sven Wischnowsky wrote: > Since `compadd' is the interface to the internals of the completion > stuff, it should be possible to use to add any words as matches. But > sometimes you probably want to use it only to have control over the > prefix/suffix- or the match-type stuff. Does this mean a compadd without new matches alters what's there already, or what's to come, or are you simply saying you can have better control over what you are adding? > So, the patch below adds the `-m' option to `compadd' > which says that the completion code should use normal matching rules > to the words given. Of course, for this the `-M' option known from > `compctl' and `complist' is also supported. This is fine. Tests with with complist (compcall must be similar) suggests that uses the standard rules, is that right? That would also be what I would guess. > Another small addition: the option `-F' says that fignore should be > used (in the same way as it's done by `compctl'). Would it not be just as easy to be able to specify a $fignore-type variable (maybe in the `compctl -k ...' fmt so you can add literals)? If it isn't, it doesn't matter, but I thought maybe that's no harder than hard-wiring $fignore in. (Does this do any more than for suf in $fignore; do for match in $matches1; do [[ $match = *$suf ]] || matches2=($matches2 $match) done done ? I can see it's a lot more efficient, anyway.) > And yet another one (this one may still be experimental): `-r ' > says that the suffix should be removed if the next character typed is > one of those given in `'. Is there a decision on how this is going to work after Bart got at the last proposal? -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy