Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: how can one let completion work *inside* zsh scripts?
- X-seq: zsh-users 3342
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-users@xxxxxxxxxxxxxx
- Subject: Re: how can one let completion work *inside* zsh scripts?
- Date: Thu, 27 Jul 2000 15:21:07 +0200 (MET DST)
- In-reply-to: Matthias Kopfermann's message of Thu, 27 Jul 2000 14:42:05 +0200
- Mailing-list: contact zsh-users-help@xxxxxxxxxxxxxx; run by ezmlm
Matthias Kopfermann wrote:
> > To zsh-workers (and everyone else interested): hm, is this becoming
> > FAQish enough to make is simplify it? For example we could allow
> > compcontext to be set to `foo()' to make it just call function
> > `foo'. And we could allow it to be set to an array and then make
> > completion offer its elements as possible completions.
> I am for it ! The easier the better. At least normally I
> tend to think that way.
I'll add something like this (mostly because it doesn't cost us
anything if compcontext isn't set).
But first some questions: _arguments and friends allow `(( 1\:foo 2\:bar ))'
to generate the matches `1' and `2' and make them be shown with
descriptions `foo' and `bar', respectively. That might be nice to have
here, too, think.
But stuffing them all in one string isn't needed here. Hm. Maybe if
all string contain an (non-backslash-quoted) colon, take everything
before them as the matches and the stuff after them as the
descriptions. People would then have to remember to quote colons when
setting compcontext from something automatically generated such as
filenames (using globbing).
And then we should allow the calling function to register a
description string for the whole set of matches (the things one gets
by setting the format style).
But that almost suggest (at least to me, striving for consistency) to
put everything into a string of the form `<descr>:<action>', where
<action> is as in _arguments, i.e.:
{...} = evaluate `...'
(1 2) = complete `1' and `2'
(( 1\:foo 2\:bar )) = complete `1' and `2' and describe them as
`foo' and `bar' in the list
Hm, is this going too far? Or should we use the array-based solution
and allow to give the description with another parameter?
Or should we just support compcontext-as-array without (a)
description(s) (and the `func()' form) and let user's use functions if
they need descriptions?
Bye
Sven
--
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author