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

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Aug 26,  4:34pm, Sven Wischnowsky wrote:
} Subject: Re: EZ-compctl (was Re: ideas: free-search-complete, noexpand)
}
} We have a new builtin that allows us to use (parts of) the completion
} code. The builtin allows us to create, change, and destroy completion
} contexts. Changing them means to add matches, to remove matches, or to 
} change matches.

Ok ...

} What we currently know as key functions that do completion would be
} implemented as widgets. The completion functions we have now are
} builtin widgets but others can be defined by the user.

Sort of, but not widgets in the sense of existing zle widgets (that is,
I don't want to have to choose just one of them to bind to the TAB key).
When you say:

} Such a widget for completion would select a shell function that
} produces the matches. I.e., no more compctls but shell functions that
} use the builtin to produce matches and that use `if...then' and other
} things for things we now do with `-x' (which will become obsolete).

I wasn't thinking of quite so much differentiation between the "widget
for completion" and the "function that produces the matches"; that is,
there's no reason the widget couldn't produce the matches directly,
and no reason the function that produces the matches couldn't also e.g.
set the autoremovable suffix or specify that menu completion be used.

(It'd also be great if every match in the list could have some of its
own attributes, e.g. prefix and suffix strings, -U-ness, etc.  But I
think that can wait for the next overhaul.)

} The builtin may offer some support for selecting a shell function
} appropriate for the current command line (of course, this wouldn't
} depend on the command line itself, but would somehow allow us to
} quickly select a (few) function(s) for certain command names or
} whatever).

Yes.

} After all selected completion-producing shell functions have been
} executed, the widget uses the builtin to say what should be presented
} to the user (e.g. show a list of matches, change the command line, or
} both, or...).

Possibly.  I was hoping all that could be set up in advance, i.e. during
generation of the matches, and then applied when the entire match list
was finally available.  (Maybe that would require per-match attributes,
which I just wrote off for now.  Hm.)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com