Re: new fake style, completion grouping etc

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Sven wrote:

> > I'm not sure that I like the idea of using the group name - seems a
bit
> > hacky. I'd be more inclined to make _arguments call _guard for some
> > special action syntax, e.g. :-/pattern/.
> 
> That's why I didn't do it yet.

I'm fairly convinced _guard needs to be using _message's -e so we need
something. If you do use the group name it should perhaps be well
commented in _guard though as it would otherwise confuse someone
someday.

> since I'm far from sure (actually, I doubt) we'll ever be able to
> cleanly fix this, we should probably re-think this.
> 
> The problem isn't just that the layout might be `not ideal', it may
> become completely messed up or without duplicates removed.

The only places we do anything special with the layout that I can think
of, it is purely to get a numerically sorted list. A compadd option for
numerically sorted groups as per my suggestion would handle that nicely
as the sorting only takes place after all matches, including fakes have
been added.

As far as I can tell, the only case where duplicates are removed is if
neither match has a description. I suppose the ideal would be for the
fake match to replace the normal match so as to potentially change it's
description. So with fake matches being added first, the first of a
duplicate could be kept within a group.

Do we ever want to have duplicates with the same description in a
group? And, do you know of any cases where the layout is anything other
than a sorted or numerically sorted list?

> We could circumvent all these problems by just admitting it and make
> faked matches be added under a different tag, i.e. in a different
> group. With a default description of `faked matches' or a user
> supplied one.
> 
> Would that be inacceptable?

To avoid all the problems (other than just layout, sorting issues), the
tag would have to be something totally separate like `faked'. To do
this would be a pity because in cases where there is more than one type
of match, we couldn't associate the fakes with either type. The result
would just be less seamless.

By using a different tag but deriving it from the real tag, e.g.
fake-users, we would only solve the layout problems. I don't think it
would be ideal though. I'd prefer to add fake matches as if they were
real ones.

> Anyway, below is that patch (including a possible fix for the
> _arguments-x thing we were discussing). Not to be committed right
now.

Looks good. I wasn't expecting the different behaviour for
f() { _wanted -x foos expl foo compadd } and
f() { _message -e foos foo }

The former gives both the description (foo) and the `No matches for'
message. This seems to be _message setting _comp_mesg. I don't think
the No matches for message is relevant when we are listing the foo
description so I think _description should also set _comp_mesg when
$xopt is -x.

I also think it might be a good idea to optionally allow a different
format string for -x descriptions - it'd just be another style lookup.

_arguments-x stuff looks fine but I only tested it briefly.

Oliver


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com