Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Problem with completion matching control
- X-seq: zsh-workers 5494
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: Problem with completion matching control
- Date: Wed, 24 Feb 1999 09:39:59 +0100 (MET)
- In-reply-to: Bart Schaefer's message of Tue, 23 Feb 1999 21:11:24 -0800 (PST)
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
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@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author