From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23682 invoked from network); 4 Feb 2002 08:58:47 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 4 Feb 2002 08:58:47 -0000 Received: (qmail 8990 invoked by alias); 4 Feb 2002 08:58:40 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16548 Received: (qmail 8979 invoked from network); 4 Feb 2002 08:58:40 -0000 From: Sven Wischnowsky MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15454.19703.823266.240649@wischnow.berkom.de> Date: Mon, 4 Feb 2002 09:57:27 +0100 To: zsh-workers@sunsite.dk Subject: Re: new fake style, completion grouping etc In-Reply-To: <3C5ACA44.BC014084@yahoo.co.uk> References: <3C486844.F6D715AA@yahoo.co.uk> <15437.15548.942083.855297@wischnow.berkom.de> <3C5ACA44.BC014084@yahoo.co.uk> X-Mailer: VM 6.95 under 21.5 (patch 3) "asparagus" XEmacs Lucid Oliver Kiddle wrote: > ... > > > Yes. Problem is the way _guard is called -- we can't easily get at > > the tag there (inside _guard) which would be needed to make sure the > > description is attached to the same group of matches as the faked > > matches (when the group-name style is used) -- otherwise the > > description would be shown more than once. I'll think about this some > > more. > > Argh. I can't think of anything better than _guard also needing to be > passed -e . Perhaps we should have _guard special cased as a form > of action in _arguments etc (despite my wish that _arguments were > simpler, utilising more separate functions). I'd have suggested > factoring out the action code from _arguments/_alternative etc if it > didn't mess up due to the internal tags use of the function stack. But in the case of _arguments, the tag is created created automatically, so the user couldn't know it (well, he could know it beacuse we know how they are constructed, but...). Maybe we should make _guard derive the name from the -[JV] argument, that would be saver than it sounds (the group name is set from the group-name style, which is tag for most people using it at all, and it would ensure that the matches are really in the same group). > ... > > This is a hard one. It's a pity that the faked matches get added before > the real ones. Yes, I've wished for a way to add them at the same time, too. But writing a `compadd' function to allow this is a bad idea, I think. > Searching through the completion system, I can't find any place where > we actually use both a sorted and unsorted group of matches together > with the same group-name. I realise it would be a big change but what I > would suggest would be to do away with the separate namespaces for > sorted and unsorted groups and just have a variable for each group to > identify the sorting style. This might then make it easy to have a > style which could change the sorting style for a particular group of > matches. I've thought about this, too, several times, but didn't dare it yet. Maybe we should just do it and make 4.1 the phase of completion code cleanup. This wouldn't really help in this case, though. Because _describe adds the matches with -V to be able to get the right layout. If one of the real matches gets added earlier, the list display will get messed up. > ... > > Sven Wischnowsky wrote: > > > > > ./Y03arguments.ztst: test failed. > > > > Grrrr... that's a result of the fake style patch. Previously, with a > > function containing: > > > > _argument '-x' ':arg:' > > > > doing > > > > foo - > > > > didn't insert anything and displayed be message `arg'. > > And it offered -x as a match (but not completing it) too right? Yes. > > This was done by some code in _main_complete which I had to change > > because otherwise adding completing a faked matched for the `arg' > > above wouldn't work. Quite naturally, actually. > > The old behaviour seemed right to me but I don't entirely understand > why the fake style required the change. If you added some fake matches and completed them everything worked fine until there was only one string matches the stuff on the line left. That one you couldn't complete. Bye Sven -- Sven Wischnowsky wischnow@berkom.de