From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24587 invoked from network); 20 Mar 2000 10:22:53 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 20 Mar 2000 10:22:53 -0000 Received: (qmail 23779 invoked by alias); 20 Mar 2000 10:22:40 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10175 Received: (qmail 23755 invoked from network); 20 Mar 2000 10:22:38 -0000 From: "Bart Schaefer" Message-Id: <1000320102230.ZM18644@candle.brasslantern.com> Date: Mon, 20 Mar 2000 10:22:30 +0000 In-Reply-To: <200003200956.KAA09431@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "PATCH: Re: ignored-patterns giving correction a go" (Mar 20, 10:56am) References: <200003200956.KAA09431@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: PATCH: Re: ignored-patterns giving correction a go MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 20, 10:56am, Sven Wischnowsky wrote: } Subject: PATCH: Re: ignored-patterns giving correction a go } } Bart Schaefer wrote: } > BTW, there's no doc for _next_tags } } Huh? 10108 contains a hunk for it. Hrm; I must have been looking at an un-rebuilt zsh.info ... it is indeed there. Sorry. } > ... 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 ... [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. } > 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. (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 ...) -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com