From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5568 invoked from network); 26 Feb 1999 12:22:53 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 26 Feb 1999 12:22:53 -0000 Received: (qmail 25983 invoked by alias); 26 Feb 1999 12:22:30 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5539 Received: (qmail 25976 invoked from network); 26 Feb 1999 12:22:28 -0000 Date: Fri, 26 Feb 1999 13:20:32 +0100 (MET) Message-Id: <199902261220.NAA31482@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Bart Schaefer's message of Thu, 25 Feb 1999 21:24:10 -0800 (PST) Subject: Re: completion parameter suggestion 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