From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2420 invoked from network); 26 Feb 1999 05:27:39 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 26 Feb 1999 05:27:39 -0000 Received: (qmail 19176 invoked by alias); 26 Feb 1999 05:27:25 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5534 Received: (qmail 19164 invoked from network); 26 Feb 1999 05:27:22 -0000 X-Authentication-Warning: awayteam.zanshin.com: schaefer set sender to schaefer@tiny.zanshin.com using -f From: Bart Schaefer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14038.12282.952091.98080@c-bart.amazon.com> Date: Thu, 25 Feb 1999 21:24:10 -0800 (PST) To: Sven Wischnowsky , Peter Stephenson Cc: zsh-workers@sunsite.auc.dk Subject: Re: completion parameter suggestion In-Reply-To: <199902241009.LAA26127@beta.informatik.hu-berlin.de> References: <199902241228.NAA26052@beta.informatik.hu-berlin.de> <199902241009.LAA26127@beta.informatik.hu-berlin.de> <9902241032.AA35507@ibmth.df.unipi.it> X-Mailer: VM 6.65a under Emacs 20.3.5.1 Reply-To: Bart Schaefer 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.