Re: new fake style, completion grouping etc

[Sven Wischnowsky <wischnow@berkom.de>]

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 <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.

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 -<TAB>
> > 
> > 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