From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: completion parameter suggestion
Date: Wed, 24 Feb 1999 13:28:33 +0100 (MET) [thread overview]
Message-ID: <199902241228.NAA26052@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Peter Stephenson's message of Wed, 24 Feb 1999 11:32:42 +0100
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@informatik.hu-berlin.de
next reply other threads:[~1999-02-24 12:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-02-24 12:28 Sven Wischnowsky [this message]
1999-02-24 10:09 ` Sven Wischnowsky
1999-02-24 10:32 ` Peter Stephenson
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=199902241228.NAA26052@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--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).