Re: completion parameter suggestion

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

Sven Wischnowsky writes:
 > (I'm asking a lot of questions lately, but I hope you agree that this
 > is correct behavior.)

I agree that you should be asking questions, if that's what you mean.

 > Most of the stuff will be put in an associative array named
 > `compstate', but first:
 > 
 > - I'd like to keep `PREFIX', `SUFFIX', and `IPREFIX' (probably
 >   renaming the last one), since I guess that `PREFIX[...]' will be
 >   used quite often

That's fine.

 > - I'd also like to keep `CURRENT' to improve readibility and make it
 >   an index into the array `words'. Slight problem with `ksharrays'
 >   here, I'd like to make `CURRENT' use the range [1,n] and explicitly
 >   describe the problem in the manual.

That's fine, too.

 > - The `words' array would contain all words from the line, including
 >   the command. Functions like `_precommand' would only have to do
 >   `shift words; (( CURRENT-- ))'. No fiddling with `compstate' since
 >   the `comamnd' and `argument' contexts would be merged into one.

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

 > - Finally the context information, an associative array. Contrary to
 >   the previous parameters this one will not automatically be restored
 >   on exit of a function. The keys are:
 > 
 >   - `matcher':     the string(!) of the global matcher
 >   - `matcher_num': what now is `MATCHER' which will be removed

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.

 >   - `num_matches': what now is `NMATCHES'

I'm with Peter on the "num" issue.  Too bad "matcher" and "matches" are so
similar.

 >   - `context':     the former `CONTEXT'
 >                    - no `argument' value
 > 		   - the `value' context could be split into `value'
 > 		     and `array_value'
 > 		   - a new value `parameter' for completion in `$...'

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

 >   - `parameter':   the name of the parameter for the `value' and
 >                    `subscript' contexts
 >   - `quote':       either a ` or a ", depending on the quoting the
 >                    code thinks we are in

It'd be fine with me to have both a `quote' and a `quoting' key, where
the first is the character and the second is a word ("single" "double"
and what, "backtick"?).  I suggested using a character because then you
don't have to think of words for all three states and you can just use
the expansion of $compstate[quote] in generated matches that want to
include the matching quote character.

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

 >   - `list':        on entry to the completion widget this is set to
 >                    one of `list', `autolist', `ambiguous', or it is
 > 		   unset (or set to an empty string)

Sounds reasonable.

 >   - `insert':      on entry this would be set to `menu', `automenu',
 >                    `unambiguous'

This sounds OK too, but maybe `prefix' rather than `unambiguous'.
Maybe.

 >   - `exact':       the completion code searches for exact matches on
 >                    the fly anyway, so we could make this information
 > 		   available

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

 > And then I'd like to make the following information available but
 > haven't found keys in which these could be combined (trying to avoid
 > too many keys and having to use too many keys for whatever purpose):

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

Peter Stephenson writes:
 > Does that mean that with ksharrays set, you would have to use
 > words[CURRENT-1] ?  Is it obvious this is better than subtracting 1 from
 > CURRENT automatically when ksharrays is set?  I suppose it is when you want
 > to test [[ $CURRENT -eq 1 ]] for the command.  Well, we'll just have to
 > make sure ksharrays is unset in all the standard functions.

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.