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

["Zefram" <zefram@tao.co.uk>]

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.

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

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

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

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

-zefram