From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2896 invoked from network); 6 Oct 2000 08:14:59 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 6 Oct 2000 08:14:59 -0000 Received: (qmail 25955 invoked by alias); 6 Oct 2000 08:14:29 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12914 Received: (qmail 25947 invoked from network); 6 Oct 2000 08:14:28 -0000 Date: Fri, 6 Oct 2000 10:14:21 +0200 (MET DST) Message-Id: <200010060814.KAA14507@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Thu, 5 Oct 2000 17:11:52 +0000 Subject: Re: PATCH: _expand, _expand_word, and their doc Bart Schaefer wrote: > On Oct 5, 7:34pm, Andrej Borsenkow wrote: > } > } > What would you (or anyone else) think of removing insert-all-completions > } > from _expand entirely (thus eliminating the -c option) and instead put > } > compstate[insert]=all at the end of _expand_word (after _main_complete)? > } > } What has inserting all *completions* to do with *expansions* (and thus > } _expand_word)? > > You're starting from an initial pattern and expanding it into a set of > strings, aren't you? What difference does it make whether the way you > got those strings was by globbing, parameter substitution, history, or > by invoking the completion system, or anything else? Right. I have to admit, though, that I put it there mainly because we were at that time using the word `expanding' for this multiple-matches insertion. Anyway. The reason why I don't really like the completions style to be handled there is that -- as Andrej mentioned once -- the matches are generated different than the expansions. Not even by _expand itself (which just looked like a clever trick at that time). So, I would mainly vote for changing the way the completions are generated, using the way we do it in _prefix and _ignore, only the other way round. I.e. we look up the completer style in the new context and use the global list if it isn't set there. From that list we remove the `uninteresting' completers as Bart did in _e_w (_prefix and _ignore should probably do the same). That way the whole thing would be self-contained again. Then we leave it either in _expand or put it into a separate completer, depending on how strongly people feel that this is different from what _expand does: the fact that we can offer expansions in different ways -- in one string or separately -- should be taken into account there, unless we make that possible for completions, too. And I think it would be possible, probably by adding a new option to compadd which makes it add a string with all matches generated so far (and then remove the `all' special value for compstate[insert]). I'm not exactly sure about the implications (inter alia because I see two different ways to implement it), but I would be willing to give it a try. With that, it would almost make sense to add that feature to _complete itself, making it look (feature-wise) more like _expand. I don't, however, like to put it only into a bindable command, because then people can't configure it to get all completions with, say, a numeric prefix and TAB. And just adding a bindable command that makes all completions be inserted when we have a completer for it is simple (or just documenting the trick with _generic). So, does that thing with allowing completions added separately to be offered together with a string with all completions sound too esoteric or do you really like it. And should we then put it into _complete? (I mean, the weekend is coming up, so I should have the time to try to implement it... ;-) Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de