Re: completion in vared

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> If there are more than 32 special completion parameters, I think we've
> failed in our goal to make the whole system easier to understand.

I'm not so sure about that. There are eight parameters, all the rest
is in compstate, not always set, etc. Sure, some of the keys in
compstate are powerful enough to be called complicated, but most of
them are quite simple, I think.

> By the way, if we're reasonably confident that we've now identified all
> the compctl-isms that it's useful to put into compadd/gen/etc., I think
> we should seriously look at rewriting the option parsing for those new
> commands to abandon the compctl syntax.  Part of the reason for creating
> the new system was because compctl was so hard to comprehend; we've made
> the new system a lot more powerful, but made little progress on making
> it easy to understand.  So far we've mostly taken the confusing compctl
> stuff, stick new command names in front of it, and wrap it in confusing
> shell-script stuff.

I'm always open to suggestions (I hope I made that clear enough from
the beginning). But I always thought the problem with compctl was the
`-x'-stuff, the `+' stuff, and things like that. This *is* removed in
the new completion system (you can't even use `+' or `-x' with
compgen), this reduces compgen to just the simple flags of compctl.

I /think/ you are referring to an old suggestion to just give a
builtin that gets the matches to be added directly (that would be
compadd) and let the user generate these matches/words through shell
code. The problem is that some of the things compgen can easily
generate currently can not be simply generated by the user (or: not as 
fast and simple). This may change if we have access to more shell
interna through special associative arrays or whatever. But still:
would this be easier to use or understand?

Again, I'd be willing to change many things if anyone gives me a good
reason to do this. I wished we had more users testing all this stuff...

> Yes, I'm exaggerating a little, but you can't really say the flow of
> control is obvious through the current set of completion functions.

Hm. Users don't have to worry about this in almost all cases. At least 
if they are writing completion functions for commands/contexts, and not 
even when writing completers, I think (which would probably count as
being something for advanced users).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx