Re: completion parameter suggestion

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> So ... this means that changes to `words' would not cause zsh to try to
> automatically update the rest of `compstate'?

In the `compstate' I described there isn't anything that would have to 
be updated (context stays the same and so on...). That's the reason
why I didn't suggest putting `CURRENT' in `compstate' and why I want
to remove the `argument' context.

> Incidentally, I've never been clear on where the "matcher number" is
> coming from in the first place, nor what one would use it for.  Maybe I
> just haven't looked through the examples closely enough.

One can give more than one global match specs (`compctl -M 'spec1' 'spec2'...),
these are tried by the completion code in order (they are `xor'ed... ouch! ;-).
`MATCHER' is the number of the one which is currently tried.

> Suppose I'm in the middle of ${$(...)}.  What's the context?  What's
> the context inside $'...'?

In the first case: `command', as always inside `$(...)'. For $'...':
same as '...'.

>  >   - `norestore':   this is always restored on exit of a function; if
>  >                    it is set on exit, the parameters above will not be 
>  > 		   reset to the values they had when the function was
>  > 		   entered
> 
> Let's try to avoid negatives, shall we?  Call it `restore' or `local' and
> have it default to set, and you unset it to prevent value restoration.  Or
> call it `scope' defaulting to `local' and you set it to `export' to make
> the other values not be restored.  But don't use a leading `no'.

Ok.

>  >   - `insert':      on entry this would be set to `menu', `automenu',
>  >                    `unambiguous'
> 
> This sounds OK too, but maybe `prefix' rather than `unambiguous'.
> Maybe.

I thought about `prefix', but decided against it since this hasn't to
be a prefix (even in older versions it could be a prefix and a suffix, 
with the matching stuff this could be a set of prefixes and suffixes).

> Two suggestions: (1) `exact' should be a possible value of the `insert'
> element mentioned above; (2) the element named `exact' should either be
> unset (when there is no exact match) or set to $word[CURRENT].  (I don't
> have a good argument for that setting, it just feels more useful than
> `yes' or `insert'.)

Again, I thought about exacly this, too. Setting `exact' to the
string: yes, possibly, I just couldn't think of something where we
might use it, but that wouldn't be a reason not to use it. But I tried 
to make the other keys contain only values that are used on entry and
after exit (with the same strings). So if we set `exact' to the match, 
the user may think that setting it to some string may make this string 
be inserted in the line. That is also the reason why I decided against 
using `exact' as one of the values for `insert'. If recexact and
automenu is set: which value should the completion code store in
`insert' (since it doesn't know if there will be an exact match
generated).

> How about another associative array called `menustate' that holds all
> these things?

As for the menu stuff, ok. But the list stuff isn't connected to
(only) menucompletion.

> The other possibility would be to automatically insert a dummy element 0
> into `words' when ksharrays is set, and automatically remove it when
> ksharrays changes.  That could be done without hooking into the option
> code if `words' was a special array with a special get-function.

Hadn't thought about that, yes maybe... (but it's the other way round, 
isn't it?)

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx