From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17325 invoked from network); 24 Feb 1999 12:29:49 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 24 Feb 1999 12:29:49 -0000 Received: (qmail 435 invoked by alias); 24 Feb 1999 12:29:24 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5502 Received: (qmail 427 invoked from network); 24 Feb 1999 12:29:21 -0000 Date: Wed, 24 Feb 1999 13:28:33 +0100 (MET) Message-Id: <199902241228.NAA26052@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Wed, 24 Feb 1999 11:32:42 +0100 Subject: Re: completion parameter suggestion 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 `' 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