Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: new fake style, completion grouping etc
- X-seq: zsh-workers 16575
- From: Sven Wischnowsky <wischnow@xxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: new fake style, completion grouping etc
- Date: Wed, 6 Feb 2002 11:49:18 +0100
- In-reply-to: <20020206093357.40994.qmail@xxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <15456.1849.401288.393433@xxxxxxxxxxxxxxxxxx> <20020206093357.40994.qmail@xxxxxxxxxxxxxxxxxxxxxx>
Oliver Kiddle wrote:
> ...
> 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.
I need to think some more then.
> ...
>
> > 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?
Layout manipulation is at the core of _describe, used for options and
values, as in the cvs-admin-k-case we were discussing. It's what
allows the nicely aligned displays of options with the same
description. Those descriptions aren't added to the matches
themselves, they are basically added as separate string to be shown
and those strings have to be added together with the matches in just
the right order. That's why we need -V-groups there.
One solution would be to put some more work into lookup of the fake
style, i.e.: change some of our utility function to look it up
themselves so that they can correctly merge the faked matches into the
normal matches they are handling. _describe, probably _arguments and
others would be candidates for special treatment. for those we could
probably add an option to _description and friends meaning that the
fake style shouldn't be handled there.
Distributing lookup of the fake style over seeral functions isn't
nice, but the treatment in some functions is so special that it
probably allows exceptions. The stuff we have now would then be used
in normal cases where it should work good enough. And if the faked
matches stick out a bit in custom-sorted lists I'm not too concerned
(or at least think that a solution for this could be postponed until
we run into problems).
> ...
>
> 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.
Actually, I don't think so. The first one tells me that we try to
complete something but there are no matches, wheres in the second case
we only display a message, not trying to complete anything.
Another option? -s for `silent' or `-q' or something?
> 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.
Suggestions for a name? Looks like a relatively simple change, indeed.
Bye
Sven
--
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author