Re: completion parameter suggestion

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote:

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

Any answer is better than no answer.

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

I thought of giving the match spec string as `matcher'. But we can
easily (probably better) use `matcher' for the number, and give the
string as `matcher_string'.

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

This was a last minute change as I thought I recalled some complaint
about it. Maybe I was just wrong.

> >   - `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?

That's what I suggested first, Bart suggested giving the quote
itself. Again, we could make this `quote=single/double' and
`quote_char='/"'.

> >   - `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 was talking about the parameters, not the keys (i.e. only `PREFIX',
`SUFFIX', `IPREFIX', `CURRENT', and `words'  would be restored).

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

One of my thoughts was to use the `insert' key for things like this,
too (and also played with `<number>' and `accept' or `next' and
`previous').

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

Right.

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

When this was added to Emacs (or, at least when I saw that this is
possible in Emacs) I had the same idea. But then, I only seldom use
menucompletion and always have problems imagining what people using it 
would like.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx