From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13728 invoked from network); 9 Oct 2000 11:50:31 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 9 Oct 2000 11:50:31 -0000 Received: (qmail 12891 invoked by alias); 9 Oct 2000 11:49:54 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12929 Received: (qmail 12884 invoked from network); 9 Oct 2000 11:49:54 -0000 Date: Mon, 9 Oct 2000 13:49:52 +0200 (MET DST) Message-Id: <200010091149.NAA18628@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Sun, 8 Oct 2000 19:35:38 +0000 Subject: Re: PATCH: _expand, _expand_word, and their doc As I said, I didn't find much time at the weekend, but I've been playing and thinking a bit. Bart Schaefer wrote: > ... > > Hm. I don't have any overwhelming disagreement with that; the issue is > not so much that _expand_word should handle it, as that _expand should > not -- Andrej is clearly correct that _match is what actually does the > most-correct thing in terms of generating the possible completions, so > the question is how to get them all (offered to be) inserted at once. As you said below, it isn't really _match either. It's any completer that generates completions. And after re-thinking, I'm not so sure about adding all completions as a single match anymore either. What Andrej suggested (using an old list) really seems most useful for me currently (getting a list, looking at it and then deciding to insert them all -- less keystrokes than menuing to the all-completions entry). (And the reason is not only that, trying a simple implementation, I had some small problems getting it to work -- problems with the prefix/suffic handling and when completing inside braces. That could probably be solved.) And the fact that _expand can offer both doesn't worry me very much either, since there we are expanding a pattern the shell would expand there anyway. It only looks slightly weird if one only things about the combination of _match and inserting all completions. > ... > > I'd say we should use a new completer which has to appear very late in > the completer list, and which modifies the handling of the completions > that are generated before it is called. As you suggest here: I agree that this ordering looks sensible, but only unless one wants it to re-use an old list. Then it should be at the very beginning, which is almost an argument in favour of code like the one in _expand. Or to put the whole thing into it's own completer that can use an old list or builds a new one, calling the other completers directly. Hm, that would also be the easiest solution and could already be implemented without having to change the C-code. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de