From: Bart Schaefer <schaefer@tiny.zanshin.com>
To: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>,
Peter Stephenson <pws@ibmth.df.unipi.it>
Cc: zsh-workers@sunsite.auc.dk
Subject: Re: completion parameter suggestion
Date: Thu, 25 Feb 1999 21:24:10 -0800 (PST) [thread overview]
Message-ID: <14038.12282.952091.98080@c-bart.amazon.com> (raw)
In-Reply-To: <199902241009.LAA26127@beta.informatik.hu-berlin.de>
Sven Wischnowsky writes:
> (I'm asking a lot of questions lately, but I hope you agree that this
> is correct behavior.)
I agree that you should be asking questions, if that's what you mean.
> Most of the stuff will be put in an associative array named
> `compstate', but first:
>
> - I'd like to keep `PREFIX', `SUFFIX', and `IPREFIX' (probably
> renaming the last one), since I guess that `PREFIX[...]' will be
> used quite often
That's fine.
> - 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.
That's fine, too.
> - The `words' array would contain all words from the line, including
> the command. Functions like `_precommand' would only have to do
> `shift words; (( CURRENT-- ))'. No fiddling with `compstate' since
> the `comamnd' and `argument' contexts would be merged into one.
So ... this means that changes to `words' would not cause zsh to try to
automatically update the rest of `compstate'?
> - Finally the context information, an associative array. Contrary to
> the previous parameters this one will not automatically be restored
> on exit of a function. The keys are:
>
> - `matcher': the string(!) of the global matcher
> - `matcher_num': what now is `MATCHER' which will be removed
Incidentally, I've never been clear on where the "matcher number" is
coming from in the first place, nor what one would use it for. Maybe I
just haven't looked through the examples closely enough.
> - `num_matches': what now is `NMATCHES'
I'm with Peter on the "num" issue. Too bad "matcher" and "matches" are so
similar.
> - `context': the former `CONTEXT'
> - no `argument' value
> - the `value' context could be split into `value'
> and `array_value'
> - a new value `parameter' for completion in `$...'
Suppose I'm in the middle of ${$(...)}. What's the context? What's
the context inside $'...'?
> - `parameter': the name of the parameter for the `value' and
> `subscript' contexts
> - `quote': either a ` or a ", depending on the quoting the
> code thinks we are in
It'd be fine with me to have both a `quote' and a `quoting' key, where
the first is the character and the second is a word ("single" "double"
and what, "backtick"?). I suggested using a character because then you
don't have to think of words for all three states and you can just use
the expansion of $compstate[quote] in generated matches that want to
include the matching quote character.
> - `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
Let's try to avoid negatives, shall we? Call it `restore' or `local' and
have it default to set, and you unset it to prevent value restoration. Or
call it `scope' defaulting to `local' and you set it to `export' to make
the other values not be restored. But don't use a leading `no'.
> - `list': on entry to the completion widget this is set to
> one of `list', `autolist', `ambiguous', or it is
> unset (or set to an empty string)
Sounds reasonable.
> - `insert': on entry this would be set to `menu', `automenu',
> `unambiguous'
This sounds OK too, but maybe `prefix' rather than `unambiguous'.
Maybe.
> - `exact': the completion code searches for exact matches on
> the fly anyway, so we could make this information
> available
Two suggestions: (1) `exact' should be a possible value of the `insert'
element mentioned above; (2) the element named `exact' should either be
unset (when there is no exact match) or set to $word[CURRENT]. (I don't
have a good argument for that setting, it just feels more useful than
`yes' or `insert'.)
> And then I'd like to make the following information available but
> haven't found keys in which these could be combined (trying to avoid
> too many keys and having to use too many keys for whatever purpose):
How about another associative array called `menustate' that holds all
these things?
Peter Stephenson writes:
> 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.
The other possibility would be to automatically insert a dummy element 0
into `words' when ksharrays is set, and automatically remove it when
ksharrays changes. That could be done without hooking into the option
code if `words' was a special array with a special get-function.
next prev parent reply other threads:[~1999-02-26 5:27 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
1999-02-26 5:24 ` Bart Schaefer [this message]
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=14038.12282.952091.98080@c-bart.amazon.com \
--to=schaefer@tiny.zanshin.com \
--cc=pws@ibmth.df.unipi.it \
--cc=schaefer@brasslantern.com \
--cc=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).