Re: completion behaviour (was: zsh-workers: zsh-3.1.5 released)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Zefram wrote:

> 
> Sven Wischnowsky wrote:
> >We had some discusssion about a new way to define completion behaviour 
> >which (seemingly) settled on: let's use shell functions and offer a
> >few new builtins. So, if I implement this, do we really want the
> >changes to compctl (note: I mean compctl, most of the changes in the
> >completion code itself would be used anyway) or should we leave
> >compctl alone and offer the new possibilities through the new way to
> >define completion behaviour, thereby giving some incentive to switch
> >to the new way?
> 
> I wondered about this myself, but came to the conclusion that new
> completion features should be made available via compctl until the new
> interface has been implemented.  After the new interface is in place we
> can freeze compctl.
> 

There seems to be more support for good ol' compctl than I expected ;-)

> >We use zle widgets, probably a new kind of widgets that uses some more 
> >special variables, like:
> 
> We can have a single widget that acts as the main interface to completion,
> creating these variables and calling user-defined widgets to do the
> real work.
> 

I meant that even the main completion widget is a user defined one and 
calls shell functions to do the real work.

> >To make the definition and calling of completion functions for certain
> >commands easier there could be a new builtin, say `compfunc':
> 
> I'm not convinced by this.  I'd rather get associative arrays working,
> and use a non-special array to store this information.  I'd like the user
> to be able to totally redefine the way that completions are associated
> with command names.
> 

Interesting. I was thinking a lot about associative arrays when
thinking about this completion definition stuff. I just didn't dare to 
suggest implementing them (and we would really need them if we have
this completion thing).
So, if we are expecting to implement associative arrays with some
really powerful mechanisms (think about the pattern matching stuff
completion will/should support), I'm all for avoiding the compfunc stuff.

> >For producing the actual matches there is another builtin, say
> >`compadd'. For simplicity we could make it use the same flags
> >`compctl' uses now, but without `-x', `+', and the like, i.e. only the 
> >simple match-producing flags. This would allow us to re-use most of
> >the code for compctl and since only the simple flags would be
> >supported, the irritating part of compctl would not be inherited.
> 
> Yes, this is good.  I was wondering how to make the match structures
> user accessible.  Using the compctl-style interface to build up a
> specially-handled list of matches solves this, and gives the user access
> to the full power of the completion system.
> 
> OTOH, I think this perhaps should be split into two builtins.  One to
> add sets of matches in a manner based on the compctl syntax (this could
> even be part of the compctl module, and use the compctl code to handle
> *all* the compctl options).  Another, more basic builtin would merely
> provide an interface for adding a single match (or a set of matches),
> with options to separately control each part of the match structure.
> 

Another one of the ideas I had, too. Yes, it would be nice to give the 
user full control about the things stored for each match (this was
part of the reason I suggested compadd with differnet options). The
old style is still interesting to have since it is much easier to use
(we store quite a bit of information with the matches).

> >is a problem with this: with compctl the `-x' - tests not only test
> >for a certain condition, but also report some information back,
> >namely: the length of an prefix that should be ignored in the
> >completion string
> 
> This should be part of the match structure, and the user should be able
> to control it explicitly.
> 

Partly agreed (see above), but I would still like to give the user
some more support. Think of `r[-exec,;]'. The user would have to do the
matching and before (s)he can produce matches (s)he would have to tell
the completion code which command words should not be used. This can
get a bit nasty.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx