From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2676 invoked from network); 25 Oct 2000 07:50:11 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 25 Oct 2000 07:50:11 -0000 Received: (qmail 21369 invoked by alias); 25 Oct 2000 07:50:06 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13081 Received: (qmail 21362 invoked from network); 25 Oct 2000 07:50:06 -0000 Date: Wed, 25 Oct 2000 09:50:04 +0200 (MET DST) Message-Id: <200010250750.JAA23801@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Andrej Borsenkow"'s message of Wed, 25 Oct 2000 11:41:14 +0400 Subject: RE: still confused about completion and matching Andrej Borsenkow wrote: > ... > > This condition predates styles. Now we do have suitable means for users to > configure desired behaviour. True. > As I said long ago, I did not want Zsh to decide for me when to start menu > completion if I did not request it. I do not want to invent another condition. > > > As I sais in one of the previous mails, I wasn't completely happy with > > that condition myself. The problem is that we certainly don't want to > > insert the unambiguous string unconditionally even if insert-unambig > > is set, because that string might often be empty. > > > > First, why are you _so_ sure there won't be any common prefix? For people that > know shell glob patterns by heart it is sometimes easier to type pattern than > to invent matching specification. And matches for foobar[1-9] are always > shorter than pattern itself. I'm not sure that it is, I'm sure that it might be... > Second, how does it differ from ordinary completion? The sole thing I wanted - > let's treat completion and matching equally. Both give you a set of matches to > select from. Let's use common rules to decide when and how these matches are > inserted. (After all, "ordinary" completion is just matching with pattern > $PREFIX*$SUFFIX ... even if not implemented this way. I do not see why > $PREFIX?#$SUFFIX should be treated differently :-) ... different from ordinary completion because there we have a lot of code that can deal with the types of matching (match specs) allowed there to build unambiguous strings without losing characters typed by the user. But I didn't want it to sound as if I'm religiously attached to the current behaviour. I'm not. We can also change it to look up the insert-unambiguous style lately, after the completions have been generated. People can then use `zstyle -e' to add conditions if they want. I guess that would be acceptable to everyone? Especially if we add a/some example(s) to the manual showing clever things one might want to try there? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de