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

[Bruce Stephens <b.stephens@xxxxxxxxx>]

Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx> writes:

> Also this is a question of personal taste, I think. At least I
> prefer a syntax that lets me get the whole power of a command even
> it is rather complicated.

Yes, I think I agree.  That's partly why I'd prefer something that
translated to compctl.  I'd definitely (as a user---presumably
developers would hate it even more) be against having two distinct
mechanisms, one for the easy stuff, and one providing the full power,
with no connection between the two.

> Anyway, I would like to go in a direction where we have a simpler
> (and more readable) form to define completions and than add some
> syntactic sugar for the most common cases. Bart suggested a syntax
> that is modeled after the normal shell syntax (if I remember and
> understood him correctly). I like that idea.

Yes, that sounds very attractive.

> Another question is if this should be implemented in an external
> program, in a new module, in the compctl module, or if we should
> make this new syntax the default and keep compctl in another module
> (which may become obsolete).

If the new syntax is better, then the last option is best: the
examples should all be provided in the new syntax, and users should be
encouraged to move to it.

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

On the other hand, if you isolate the completion stuff into separate
files, then that probably makes things a lot saner (there're surely
going to be ambiguities otherwise), and it leaves open the possibility
of "byte compiling" the completion files for speed.  Anyway, as a
first step, using separate files looks fine.

I don't really have any comments about your proposed syntax: it looks
very readable.  With documentation (so that I know which words are
keywords and which are strings) it'll be great, but even so it looks
good.

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.  

I can't offhand think of a general example, but two of Isode's tools
have this property.  tcldish and ltcldish are basically the same:
they're shells which connect to X.500/LDAP directories.  Both take the
same kinds of arguments for authentication and things, but tcldish has
an -call option which has an X.500 presentation address argument,
whereas ltcldish has a -call with an LDAP URL.  

It would be nice to have the common arguments separated out, and be
able to define tcldish saying that it accepts these arguments,
together with these extra (unique) ones.  I'm sure there are lots of
other cases where this would be nice.  MH may be another one.  

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.