From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24710 invoked from network); 20 Mar 2000 10:40:24 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 20 Mar 2000 10:40:24 -0000 Received: (qmail 2478 invoked by alias); 20 Mar 2000 10:40:11 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10177 Received: (qmail 2447 invoked from network); 20 Mar 2000 10:40:07 -0000 Date: Mon, 20 Mar 2000 11:40:05 +0100 (MET) Message-Id: <200003201040.LAA10023@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Mon, 20 Mar 2000 10:22:30 +0000 Subject: Re: PATCH: Re: ignored-patterns giving correction a go Bart Schaefer wrote: > ... > > [_next_tags] > } > ... what happens if you invoke it as > } > a widget but it's NOT in your completer list? > } > } The end of civilisation as we know it... > > The point being that perhaps it should not be bound to a key by compinit > if it's not in the completer list by default ... Ah, right. The patch does that (I think this is saver than changing the default completer value). > [Trailing -number on completer context] > } No, it's only used for matcher-list and prefer-ignored, as documented. > } Just so that I don't forget it, the patch below takes back a part of > } your doc change. *But*: should we change it so that your documentation > } becomes true? > > It's too bad those things have to be wedged into the context string. > It feels as though they should be somewhere else. > > } I played with this idea, too... One problem: approximate > } (and correct) use the same syntax already to include the number of > } errors currently accepted. So we would have `complete-1', > } `correct-1-2' and so on > > I don't think I like having two such suffixes on the same completer. Yep, that's why I didn't do it. > } > So what if we just made the alternate set a group of its own, on the > } > same level as the -default- group, e.g. -alternate-. Change the -a > } > option of compadd to require an argument, `-a alternate-group-name' > } > } Yes, I once thought about using a different group, too. Hadn't thought > } about allowing users to give it a name, though... Hm. What makes me > } uneasy about it is that this would make it even more complicated. > > I'm not especially worried about it being complicated for people who are > deep enough into it to be writing functions that use alternate sets. The > people who have to configure it are the ones who should get off easy. It's also that the alternate set stuff as it is now only gives you all or nothing. One can't say that one *never* wants to see some matches. As soon as there are no other matches, the alternate set code will give you the excluded ones. If we implement ways to completely handle such exclusions-or-not in shell code, users would be able to say which matches they never want and which matches they may want -- and when. > (Back when we first started discussing the new completion system, my idea > was that lots of people would need to write their own completers, and I > was worried about making the functions easy to understand. Now we have a > huge library of highly configurable functions, so hardly anyone is going > to need to write one ... it _should_ be easier to configure the ones we > have than it is to write new ones ...) Yes. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de