RE: PATCH: was RE: PATCH: old lists compstate

["Andrej Borsenkow" <borsenkow.msk@sni.de>]

I get a feeling, you are going to hate me ...

So, do I understand it correctly:

1. The first TAB always inserts the longest prefix and throughs the list
away. If autolist is set but listambiguous is unset, list is displayed
immediately.
2. The second TAB reruns the completion and finds out, that no more
unambiguous prefix exists. If autolist and listambiguous are both set, the
list is displayed now and nothing is  inserted; list is thrown away. If
autolist is unset, list is retained for possible menucompletion
3. Only if both autolist and listambiguous are set - the completion code is
rerun again on third TAB - and nothing is inserted
4. Finally, automenu cuts in on the forth TAB.

I just tried it with vanilla zsh -f; just try ls ChTAB in zsh top level dir
:-) Look:

bor@itsrm2:/tools/src/zsh-3.1.5-pws-14%> zsh -f
itsrm2% l Ch<TAB>
itsrm2% l ChangeLog<TAB>
itsrm2% l ChangeLog<TAB>
ChangeLog       ChangeLog.3.0   (beep)
itsrm2% l ChangeLog<TAB>
ChangeLog       ChangeLog.3.0    (beep)
itsrm2% l ChangeLog.3.0
ChangeLog       ChangeLog.3.0

So, I need four TABS to get at the automenu completion.   _path_files does
it on the third TAB. confused.

>
> You wrote:
>
> > with automenu without autolist, listambiguous
> >  - menu is started at the second TAB. List is never shown.
> Cursor moves to
> > end of word when menu starts
> > with automenu,autolist without listambiguous
> >  - list is shown at the first tab; menu at the second TAB;
> cursor moves to
> > the end of word when menu starts
> > with all three set
> >  - list is shown at the second TAB; menu is started at the
> third TAB; cursor
> > is moved at the end of inserted string when menu starts!
>
> The difference in cursor placement is a -- probably somewhat ugly --
> interference between `listambiguous' and `automenu'. On the first TAB
> it inserts the unambiguous part (non-menucompletion).

in all three cases? So it looks like. And in all three cases cursor is (at
least, optically) left after inserted string.

On the second
> TAB it runs through the completion code again and finds nothing
> unambiguous to insert so that `listambiguous' means to show the list
> now. Before this the cursor was in the middle of the word.

But this is (at least, optically) in all three cases.

The third
> TAB runs the completion code again, but immediatly starts
> menucompletion, the real completion code (generating matches) is not
> run. Different from the other two cases menucompletion is now
> started when the cursor is already in the middle of the word (which is
> remembered by automenu).

Ehem ... the cursor is in the same place in all three cases for all I can
tell.

In this case menucompletion always left the
> cursor there instead of moving it to the end.
> The problem is, of course, that one has to realise that the first two
> TABs do normal completion and since that leaves the cursor in the
> word...
>

The difference (if the four steps at the beginning are correct) seems to be,
that not previous, but "one before previous" position seems to be
remembered. That looks really strange in view, that the list built by the
first TAB is discarded in any case and we start from scratch the on the
second TAB ... and in all three cases the cursor is in *exactly* the same
position.

> Now try `setopt alwaystoend'...
>

Well, it always moves to the end ... where I'd like to see an option to stay
in word :-)
But in any case, it looks more like a bug to me ...

regards

/andrej