Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

# Re: completion parameter suggestion

• X-seq: zsh-workers 5501
• From: Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>
• To: zsh-workers@xxxxxxxxxxxxxx
• Subject: Re: completion parameter suggestion
• Date: Wed, 24 Feb 1999 11:32:42 +0100
• In-reply-to: "Sven Wischnowsky"'s message of "Wed, 24 Feb 1999 11:09:26 NFT." <199902241009.LAA26127@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm

> (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
on exit
(use existing number to determine new one)
context[menuitem]=accept       accept the current one   ) initial letter

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



Messages sorted by: Reverse Date, Date, Thread, Author