new completion behaviour version 2

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Ok, here is the update I promised...

We need some kind of C-wrapper function around the completion code, so 
we either have one new builtin widget that calls a shell function to
do the real work or we have a new type of user-defined-widgets which
do the work, probably calling other shell functions to produce the
matches.

Information about the context for producing the matches is normally
obtained in the top level shell function (or the new-type widget),
stored in local variables and thereby made accessible in called
functions, but of course users can implement this differently. Of the
information that is important to have the command words and the index
into this array are already available via `read'. The prefix and
suffix can be made accessible via `read', too, or as arguments when
calling the top level function (as with compctl-K-functions). Another
interesting information is the environment, i.e. `condition',
`redirection', and the like, which could be made accessible like the
prefix/suffix. To be able to implement things like xor'ed completion
in a shell function we need a way to access the number of matches
produced so far. This information differs from the other ones because
it changes whenever matches are added (of course). If we avoid special 
variables for all the other things we shouldn't add one for this, so
the users will have to call `read' repeatedly to get the current
number of matches.

Since most people will put their completion definitions in shell
functions, we need a way to at least map strings (command names) to
other strings (function names). This will be done either with
associative arrays or with the `$funcs[$cmds[(i)$CMDNAME]]'-trick. For 
command name patterns we can start using a simple array until we find
something more clever.

For producing matches we have a new builtin that uses the
compctl-flags (and part of it's code) to specify which matches should
be generated. Either this builtin or another new builtin will support
a way to directly set all the different things that are stored
together with the matches.

The coding scheme for xor'ed completion is trivial. The code for `-x'
stuff will be done using `if'-tests with the information stored in
local variables. We then need a way to notify the completion code
about two things it will have to use (to be able to do the same things 
`-x' can): the length of an ignored prefix of the current word and
(for `-L') which part of the words-array should be taken as command
words. Of course we should do this in a very general manner, giving
users the possibility to report restrictions `-x' doesn't use. To be
able to correctly save/restore this type of information we will need a 
way to get the current state in a way that can be used to restore it
later (so that independently developed completion functions can
restore the restrictions to the state they were in when the function
was called). All this could be done with the builtin that produces the 
matches (or the one that gives full control over the match structure
if we put this into a separate builtin).

Finally we need a way to put a match in the command line and to list
matches. Listing is simple (one way or the other). More interesting is 
putting matches on the line. I still find it tempting to think about
ways to use the special variables [LR]BUFFER for this. The only
problem with this are automagically removed suffixes (getting the
prefix/suffix from the completion code is simple nowadays). So if we
add a way to make removable suffixes completely user-controllable this 
may be the best solution (and giving the user full control over this
is interesting in itself, just think about the `compctl ... -S/ -q'
example from Bart). So we would end up with a builtin that allows one
to retrieve information about the matches (the prefix/suffix to
insert, and probably all the other things stored with the matches),
starting a new set of matches, listing them, and so on. With this
builtin we could also let users remove specific matches, change them,
etc. All this could later be added if we find uses that make them
desirable.

So, I hope this approach is simple enough. Comments?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx