new fake style, completion grouping etc

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

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 <tag>. 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<TAB>
> > ---- 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 -<TAB>
> 
> 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
________________________________________________________________________