From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: completion parameter suggestion
Date: Fri, 26 Feb 1999 13:20:32 +0100 (MET) [thread overview]
Message-ID: <199902261220.NAA31482@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Bart Schaefer's message of Thu, 25 Feb 1999 21:24:10 -0800 (PST)
Bart Schaefer wrote:
> So ... this means that changes to `words' would not cause zsh to try to
> automatically update the rest of `compstate'?
In the `compstate' I described there isn't anything that would have to
be updated (context stays the same and so on...). That's the reason
why I didn't suggest putting `CURRENT' in `compstate' and why I want
to remove the `argument' context.
> 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.
One can give more than one global match specs (`compctl -M 'spec1' 'spec2'...),
these are tried by the completion code in order (they are `xor'ed... ouch! ;-).
`MATCHER' is the number of the one which is currently tried.
> Suppose I'm in the middle of ${$(...)}. What's the context? What's
> the context inside $'...'?
In the first case: `command', as always inside `$(...)'. For $'...':
same as '...'.
> > - `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'.
Ok.
> > - `insert': on entry this would be set to `menu', `automenu',
> > `unambiguous'
>
> This sounds OK too, but maybe `prefix' rather than `unambiguous'.
> Maybe.
I thought about `prefix', but decided against it since this hasn't to
be a prefix (even in older versions it could be a prefix and a suffix,
with the matching stuff this could be a set of prefixes and suffixes).
> 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'.)
Again, I thought about exacly this, too. Setting `exact' to the
string: yes, possibly, I just couldn't think of something where we
might use it, but that wouldn't be a reason not to use it. But I tried
to make the other keys contain only values that are used on entry and
after exit (with the same strings). So if we set `exact' to the match,
the user may think that setting it to some string may make this string
be inserted in the line. That is also the reason why I decided against
using `exact' as one of the values for `insert'. If recexact and
automenu is set: which value should the completion code store in
`insert' (since it doesn't know if there will be an exact match
generated).
> How about another associative array called `menustate' that holds all
> these things?
As for the menu stuff, ok. But the list stuff isn't connected to
(only) menucompletion.
> 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.
Hadn't thought about that, yes maybe... (but it's the other way round,
isn't it?)
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~1999-02-26 12:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-02-26 12:20 Sven Wischnowsky [this message]
1999-02-28 3:09 ` Bart Schaefer
-- strict thread matches above, loose matches on Subject: below --
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
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=199902261220.NAA31482@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).