Zsh Mailing List Archive
Messages sorted by:
Re: EZ-compctl (was Re: ideas: free-search-complete, noexpand)
- X-seq: zsh-workers 4339
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxxx
- Subject: Re: EZ-compctl (was Re: ideas: free-search-complete, noexpand)
- Date: Thu, 20 Aug 1998 13:17:01 +0200 (MET DST)
- In-reply-to: Bruce Stephens's message of 20 Aug 1998 11:48:13 +0100
Bruce Stephens wrote:
> > Since I wouldn't like to mess with the shell lexer/parser just to
> > add a new syntax for completion control, I would (as a first step)
> > implement it as a new builtin that gets some filenames arguments (or
> > read stdin), reads these files and expects the new syntax there.
> I think there's potential for confusion. If completions use
> functions, I'd want to put the function definitions in the same file
> as the completion. Similarly, I might want to define an array in the
> same file, too. There might be a case for having files which define
> functions together with completions for them.
Yes, I was aware of that problem. If the completion control command
would read stdin we could put it into the normal setup files with the
definitions in here-documents (which is a bit ugly). Also we could
allow the definition of array/variables and functions in the
definition files (at least I think, we could do that).
> An extra feature I'd like to see (which may be in your suggestion, but
> I missed it if so) is sharing of components. Most commands have
> basically the same structure: a set of options (with - or --) with
> arguments, and then an optional list of files. Quite a few commands
> share a number of options, but not all of them.
There are two ways to do that: with some compctl stuff or with some
kind of `alias' in the command that interprets the definition
files. The second one doesn't look too hard and the first one is
possible with my last changes, more exactly the fixes to the `-l'
flag. With that, one can do:
compctl ... __common_options
compctl ... -l __common_options ... foo
to `include' the flags from `__common_options' into the definition for
the command `foo' (in fact, this was the reason why I gave the `-l'
flag an optional argument, unfortunately this never quite worked until
> Maybe it would be useful to have special support for cvs-like commands
> too, where cvs takes some options, and a subcommand, and each
> subcommand has its own set of options and arguments, many shared. But
> maybe not: there probably aren't enough commands like that for it to
> be worthwhile.
This too should be easy enough with a combination of `-x' and the `-l'
stuff mentioned above.
Of course, this could be one of the things for which some kind of
short-cut notation may be interesting.
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by: