Re: completion parameter suggestion

[Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>]

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

It depends what you think of the answers...

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

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.

>   - `matcher_num': what now is `MATCHER' which will be removed

Since `num' is not a word, I'd be quite happy with just `matcher' as
before.

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

Same problem: nmatches is probably just as good here.  It looks sufficienly
like $n_\mathrm{matches}$ for anyone with a mathematical upbringing.  It
would be nice to have something neater, but the only thing I can think of
is `matchcount'.

>   - `quote':       either a ` or a ", depending on the quoting the
>                    code thinks we are in

How about 'single' or 'double', since most of the context is going to be in
words?

>   - `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 (with this we can finally implement helper
> 		   functions that do tests and modify the parameters
> 		   without having to make the helpers call other
> 		   functions that produce the matches)

But num_matches will be changed anyway if new matches were added in the
function, so in most cases you won't want to restore that on exit anyway.

>   (I'm not yet too sure about the following ones, suggestions are
>   especially welcome.)

These sound pretty good.

>   - if there currently is an older and still valid set of matches
>   - if this set is displayed on the screen
>   - if this set should be kept, the set build by the completion widget 
>     would be discarded (this new set will be empty in most cases)
>   - if we are currently in a menucompletion, with that, probably:
>     - the total number of matches in the set we are menucompleting
>     - the number of the match currently on the line
>     - make the code insert the n'th (or n'th next/previous) match
>     - make the code accept the current match and continue
>       menucompletion

I'll think about these.  I can see the problem; if you just have e.g.
$context[curlist], then on entry it can be e.g. valid, displayed, none, but
on exit you would want it to be something like keep, so it looks a little
inconsistent, and other functions can't get the old value.  Maybe that's
OK, though.  If so, we could do something like
on entry
  $context[menuitem] = "11/20"   11th out of 20 shown (blank if not
                                 menu-completing)
on exit
  context[menuitem]=14           insert the fourteenth match
                                 (use existing number to determine new one)
  context[menuitem]=accept       accept the current one   ) initial letter
  context[menuitem]=continue     accept-and-menu-complete ) probably OK

On the other hand, with a special associative array polluting the name
space is not such a big worry.

My dream is of being able to highlight an item in the list and move through
it with the cursor keys to pick one.  It's not impossible --- add some
highlight information when sending to zle_refresh(), remember rows and
columns, hit return to accept, escape to cancel the selection cursor ---
but it's still a way off.

-- 
Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy