From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16746 invoked from network); 15 Feb 1999 09:44:23 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Feb 1999 09:44:23 -0000 Received: (qmail 29484 invoked by alias); 15 Feb 1999 09:43:56 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5381 Received: (qmail 29477 invoked from network); 15 Feb 1999 09:43:49 -0000 Date: Mon, 15 Feb 1999 10:42:13 +0100 (MET) Message-Id: <199902150942.KAA24038@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: opk@thoth.u-net.com's message of Sun, 14 Feb 1999 19:35:25 +0000 Subject: Re: Problem with completion matching control Oliver Kiddle wrote: > I've noticed the following behaviour which makes some sense but seems > like a bug when first noticed. > > zsh -f > :> Temp > :> temp > compctl -M 'm:{a-z}={A-Z}' > less t > > Results in > less temp > ^ - Cursor here. 'Temp' and 'temp' are listed below > > So it if filling in the 'emp' which is unambiguous but moving the cursor > back which I find very annoying. In my opinion, it should either > complete to 'temp' or just beep and list the two files. The former would > probably be better. Can the semantics of matching control be changed to > accomodate this with out breaking it's other uses? i.e. Are there cases > where the cursor moving back is useful? As for the inserting and listing of matches: the explicitly used matching spec makes both names possible matches, so only they should be used and shown (after all that's what all this matching stuff is about). As for the cursor position: I tried to make the completion code clever here by making it leave the cursor in the place where it is easiest to make the inserted line unambiguous. I know that this may look irritating but I think that this is the right thing to do. I could be convinced to make this controlled by an option, so that the cursor is left at the end if the option is unset. Playing with this I also noticed that there is some weird interaction going on between inserting such a string and the setting of recexact (the exact inserted match isn't immediatly accepted, which is wrong if auto_menu is unset). I'll have a lokk at this. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de