From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11008 invoked from network); 1 Feb 2002 17:03:45 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 1 Feb 2002 17:03:45 -0000 Received: (qmail 26875 invoked by alias); 1 Feb 2002 17:03:33 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16539 Received: (qmail 26855 invoked from network); 1 Feb 2002 17:03:30 -0000 X-VirusChecked: Checked X-Authentication-Warning: iris.logica.co.uk: Host rambo.logica.co.uk [158.234.33.58] claimed to be yahoo.co.uk Sender: kiddleo@iris.logica.co.uk Message-ID: <3C5ACA44.BC014084@yahoo.co.uk> Date: Fri, 01 Feb 2002 17:03:00 +0000 From: Oliver Kiddle X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.16-686-smp i686) X-Accept-Language: en MIME-Version: 1.0 To: zsh-workers@sunsite.dk Subject: new fake style, completion grouping etc References: <3C486844.F6D715AA@yahoo.co.uk> <15437.15548.942083.855297@wischnow.berkom.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sven Wischnowsky wrote: > Good idea (although I'd probably take a different option letter there > (where function writers can see it)). The patch below doens't contain > this, because we should then change _description and all the functions > that call it (not only _wanted), I'll look into this. Yes, I realised it would need all the various _description calling functions to take it. I'd prefer more of them to use zparseopts anyway because it is easier to then read them. > 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. Sven Wischnowsky wrote: > > Felix Rosencrantz wrote: > > > host@ zstyle :completion::complete:cvs-admin:option-k-1:option-k-1 fake > > b:binary > > host@ cvs admin -k > > ---- keyword substitution > > b -- binary > > b k kv kvl o v > > > I've had a closer look at this. It's because calling _describe adds > the faked matches in a -V-group and later the normal matches are added > in a -J-group. > > Hrm. Both showing -V- and -J-groups together or removing duplicates > in such pairs of groups with the same name could mess things up > terribly, so that's not a possible solution. This is a hard one. It's a pity that the faked matches get added before the real ones. 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. Backward compatibility wouldn't be too bad because we haven't really ever mixed sorted/unsorted matches with the same group name. Though it would be tempting to rename -J to -G, remove -V and have a -o taking arguments to indicate sorted, unsorted, numeric ordering, sort by description, a comparison function or whatever else. However I do realise that with groups and sorting dating back to compctl this would be no small change. Sven wrote: > You mean removing the separate-sections style? I've added that > because I couldn't think of a way to get the other description (for > the case when the matches from all sections are shown together) > without adding it. That would require some (probably serious) changes > to the group-name style, whose implementation is currently nicely > simple, so I was reluctant to even try that. Is the solution with the > new style so ugly that we have to try? I don't think it is so ugly, I just thought it would be better to have a more generalised grouping style instead. I've never thought it ideal that you still get several descriptions when you group several types of matches together. 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? > 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. I'd have thought that any description added with -x should potentially block other matches from being completed with the _guard tactic being employed so that other things get completed. This allows the lists of options to be displayed though it might be useful if additional uses of the tab key allowed completing of the options (menu selection doesn't seem to even work for this case in 4.0.4). Or am I misunderstanding this problem? Oliver ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________