Re: EZ-compctl (was Re: ideas: free-search-complete, noexpand)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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 
now).

>
> ...
> 
> 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.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx