From: Peter Stephenson <pws@ibmth.df.unipi.it>
To: zsh-workers@sunsite.auc.dk
Subject: Re: completion parameter suggestion
Date: Wed, 24 Feb 1999 11:32:42 +0100 [thread overview]
Message-ID: <9902241032.AA35507@ibmth.df.unipi.it> (raw)
In-Reply-To: "Sven Wischnowsky"'s message of "Wed, 24 Feb 1999 11:09:26 NFT." <199902241009.LAA26127@beta.informatik.hu-berlin.de>
> (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@ibmth.df.unipi.it> Tel: +39 050 844536
WWW: http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy
next prev parent reply other threads:[~1999-02-24 12:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-02-24 12:28 Sven Wischnowsky
1999-02-24 10:09 ` Sven Wischnowsky
1999-02-24 10:32 ` Peter Stephenson [this message]
1999-02-26 5:24 ` Bart Schaefer
1999-02-26 12:20 Sven Wischnowsky
1999-02-28 3:09 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9902241032.AA35507@ibmth.df.unipi.it \
--to=pws@ibmth.df.unipi.it \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).