From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15471 invoked from network); 24 Feb 1999 08:41:01 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 24 Feb 1999 08:41:01 -0000 Received: (qmail 12272 invoked by alias); 24 Feb 1999 08:40:47 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5494 Received: (qmail 12265 invoked from network); 24 Feb 1999 08:40:46 -0000 Date: Wed, 24 Feb 1999 09:39:59 +0100 (MET) Message-Id: <199902240839.JAA25905@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Bart Schaefer's message of Tue, 23 Feb 1999 21:11:24 -0800 (PST) Subject: Re: Problem with completion matching control Bart Schaefer wrote: > Sven Wischnowsky writes: > > > > +/* This says what of the state the line is in when completion is started * > > + * came from a previous completion. If the FC_LINE bit is set, the * > > + * string was inserted. If FC_INWORD is set, the last completion moved * > > + * the cursor into the word although it was at the end of it when the * > > + * last completion was invoked. * > > + * This is used to detect if the string should be taken as an exact * > > + * match (see do_ambiguous()) and if the cursor has to be moved to the * > > + * end of the word before generating the completions. */ > > Is that really good enough? Can't the cursor sometimes move from one > place in the middle of a word, to some other place in the middle of > the same word, depending on exactly what matches are generated? > Particularly in the case (ahem) of a case-insensitive matcher? As long as the line isn't changed by the user, the code places the cursor always in the same place. If the line is changed, this flag is reset anyway and the code places the cursor somewhere else anyway. Yes, as far as I can think, this should solve the problem. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de