Re: new completion behaviour version 2

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> ...
> 
> 
> If we're going to add associative arrays anyway (which I take it would
> just be some kind of parameter syntax for frobbing a hash table) then
> I'd just as soon have the set of scalars (CMDSTR, CURWORD, etc.) be in
> such an associative array.

Interesting idea, I'll have to think about this a bit more...

> 
> As for the words of the current command ... I'm thinking I'd like them
> to come in as the positional parameters.  We already have syntax for
> altering the $* array (shift, set, and 3=foo among other things); it
> should be possible to recapture the contents after the function exits;
> and it is an extremely intuitive way to refer to the command line.
> 
> (You can almost do this today by using
> 	read -Ac argv ; shift
> in a compctl -K function, except that stomps the $1/$2 prefix/suffix.)

Yes, sounds good.

> 
> } For producing the actual matches there is another builtin, say
> } `compadd'.  [...]
> } with a different way to handle control flags (-U, -q,
> } grouping,...). We could make these flags be used `from now on' and
> } probably have a way to save/restore the current set of control flags
> } (whose state would be stored together with the matches produced),
> } e.g. (in an easy-to-read syntax):
> } 
> }   compadd -push
> }   compadd -quote -suffix '/'
> }   compadd -files               # optional glob pattern here
> }   ...
> }   compadd -pop
> 
> The main problem I have with this is that it's too easy to forget the
> "pop".  If you want to do something of this sort, it really needs its
> own syntax.  One way to accomplish that without having to muck about
> with the zsh parser is to supply ONLY the "push" version of the command,
> but define it to extend exactly to the end of the current function, as
> for "local" variables and "setopt localoptions".  The user can control
> scope by defining functions that call one another.
>  

I wasn't too happy about this, just because this `pop'. On the other
side I think that the function scope may be too big for this. But
maybe we can just do what you suggest and if we find out that we would 
like to have a possibility to `pop' to a previous state we can add it
later.

> } I.e. use the normal shell tests and the special variables. But there
> } 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 and (with `r[a,b]') a restriction on the command
> } words that should be used with `compctl -L'.
> 
> Pardon my density, but I don't follow the connection between r[a,b] and
> `compctl -L'.  Do you mean `compctl -l'?

Yep, of course, this was a typo.

> 
> }   complist -k
> }   complist -c
> 
> Incidentally, with respect to menu completion, I don't think the widget
> should get involved directly in cycling through the menu choices.  (I
> can easily be convinced otherwise, but right now I don't see a compelling
> argument.)  Once the the control flags have indicated that you have a
> menu of choices, don't invoke the widget again until the prefix changes.
> That is, the widget can say "here are the completions, and here is where
> you insert them" but then let hardwired code take over cycling through
> the menu if there are multiple matches.

Interesting point of view. I thought we wanted to give the user the
possibility to build widgets that have full control over the
completion mechanism, i.e. the possibility to re-implement all the
things the completion code offers now.
But again, yes, we probably should start with a minimal solution and
improve that later if we need/want to have it.

> ...
> 
> Recexact can be emulated entirely by the wiget by simply producing only
> a single match.  Listambiguous can be a flag attached to the generated
> list of matches, can it not?
> 

Yes. The question is: should the completion code do this automatically 
or should the user request it explicitly.

> ...
> 
> What I had in mind a while back was an interface to add one or more
> matches with options for the controls associated with that collection
> of matches; plus interfaces (possibly commands, possibly variables) to
> obtain the information that's currently only available to compctl and
> pass it to the add-matches interface.
> 
> So for example there would be a command or an array variable that gives
> the names of all the disabled commands, and you'd do
> 
> 	compadd $disabled
> 
> instead of
> 
> 	compadd -dFB
> 
> (That's probably not the best example, but just to give the idea.)
> 

I like this. But I wouldn't like to have to do

    compadd $(compinfo -disabled)

The $(...) is what I don't like. Using variables would be much more
effective, but these would be special variables and there seems to be
reluctance against more special variables (not from me, I always liked 
them).

> ...
>
> I agree, and I liked your comptest idea.  For example, something like
> 
> 	if comptest index -1 / ; then
> 
> to mean what n[-1,/] accomplishes now.  (There could even be a flag in
> [[ ]] to mean "test completions", e.g., [[ -C index -1 / ]] for the
> above.)

I didn't think about changing [[...]], interesting. (Although that
would require changes in completely differnt parts of the code, of
course.)

> ...
> 
> Recursively invoking completion functions is a good idea, and IMNSHO is
> the best argument that I can think of for passing the command words as
> the positional parameters.  (There is of course still the issue of $0,
> but that's not too terrible.  Just assign to CMDSTR or whatever takes
> its place in the associative array, before calling the other function.)

Of course. My suggestion was to have a top-level function that calls
other functions which might call other functions...


> 
> On Nov 3,  4:58pm, Sven Wischnowsky wrote:
> } Subject: new completion behaviour version 2
> }
> } 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.
> 
> I still think you must mean `-l' there.  Un-confuse me, please.

Yes, this was `copying a typo without further thinking'.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx