Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: match again
- X-seq: zsh-workers 9513
- From: Peter Stephenson <pws@xxxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: match again
- Date: Tue, 01 Feb 2000 18:45:30 +0000
- In-reply-to: "Sven Wischnowsky"'s message of "Mon, 31 Jan 2000 14:01:49 +0100." <200001311301.OAA03360@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
Sven Wischnowsky wrote:
> But, before we start modifying docs are something like this, I'd like
> to repeat the question: would it be ok for everyone to make completer
> names be preceeded by two colons? With that we could use this kind of
> pattern:
>
> > That means this example from the doc is wrong, does it not?
> >
> > To be able to share the same specifications one has set up for the
> > GNU version of the ls command one can use:
> >
> > zstyle ':completion:*:default' list-colors ${(s.:.)LS_COLORS}
> > ^^^
>
> ... which is indeed wrong for the current state of the code. And I
> really, really don't like having to use patterns like `:completion*:...'.
> The only reason I didn't do that was because I had added the `::cmd:'
> thing at that time already.
It looks better, but is it enough to sort out all possible cases where you
might want to use `:*:'? Or are there even more cases where we might get
into trouble with that? I'm worried we could be barking up the wrong tree,
and should, for example, fix the fields of the pattern to
e.g. :completion:completer:command-or-context:arguments:tag (this may not
even be complete) with unrequired fields set to null strings but retaining
the colons, so you can always guarantee to pick out the appropriate
bit (unless there are extra colons inside the fields). This will mean a
lot of multiple colons, but I don't think that's a major problem (in fact,
that's where we're heading anyway).
Any other uses of colons in the pattern --- e.g. to indicate a command name
--- would have to be rethought, but replacing the second `:' by a `-' might
be enough. Or just have commands and other contexts specified in different
fields (i.e. one is ...::command:... and the other ...:context::).
Probably the big headache would be enforcing consistency in the code as it
stands --- virtually every use of styles would have to be rewritten. But
I like the idea that you can set `acontext=(${(s.:.)curcontext})' and pick
a particular word of $acontext to check.
> And: any suggestion for how to test the completer style with a tag?
> Use the `default' tag (that just sounds weird, somehow, but maybe this
> is only my problem).
Well, with the way described above it becomes much clearer what an empty
tag means. You'd have something like `:completion::::'.
--
Peter Stephenson <pws@xxxxxxxxxxxxxxxxxxxxxxxx>
Messages sorted by:
Reverse Date,
Date,
Thread,
Author