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

["Andrej Borsenkow" <borsenkow.msk@xxxxxx>]

> > bor@itsrm2:~%> l /t/s/gl/co<TAB>
> > bor@itsrm2:~%> l /tools/src/glib-1.<TAB>/config
> > bor@itsrm2:~%> l /tools/src/glib-1.<TAB>/config
> > glib-1.1.15/  glib-1.2.0/
> > bor@itsrm2:~%> l /tools/src/glib-1.1.15<CURSOR>/config
> > glib-1.1.15/  glib-1.2.0/
>
> That's without menucompletion, but with automenu, right?
>

Yep.

> > that is O.K., but
> >
> > bor@itsrm2:~%>  compconf completer=_menu:_complete:_match
> > bor@itsrm2:~%> l /t/s/gl/co<TAB>
> > bor@itsrm2:~%> l /tools/src/glib-1.1.15/config.cache <CURSOR>
> > glib-1.1.15/  glib-1.2.0/
>
> Leaving the cursor at the end is normal menucompletion behavior. Then
> I was about to say that to have the cursor in the middle, you have to
> add a `compstate[to_end]=single' for normal menucompletion and a
> `compstate[to_end]=""' for `_menu' -- when I discovered the bugs fixed
> by the patch below. And now I can say it.
>

And I can confirm, that it did the trick :-) But the question I have, is -
what is the difference? I mean, in both cases we have menu completion. In
both cases to_end is set to single (am I wrong?) and is not reset (except in
_menu now). But these two behave differently. And even more differently, as
here is what I get with _menu (after I set to_end to "":

bor@itsrm2:~%> l /t/s/gl/co<TAB>
bor@itsrm2:~%> l /tools/src/glib-1.1.15<TAB>/config.cache
glib-1.1.15/  glib-1.2.0/
bor@itsrm2:~%> l /tools/src/glib-1.1.15/config.guess
glib-1.1.15/  glib-1.2.0/

Note, that the list is shown for some part of path, but menu completion
cycles through the last component.

Please, understand me. I find it great, that it is possible to program menu
(and list) via shell function - but, then, I'd like to know, how to get at
least the same behaviour as builtin :-) And what I see here, seems to be
plainly wrong in any case.


>
> Nonono. bashautolist shows the list on the *third* TAB if something
> unambiguous could be inserted on the first TAB. listambiguous shows it
> if nothing unambiguous could be inserted. And in your example there
> definitly was a lot unambiguous stuff inserted on the first TAB.
>

What is interaction with autolist+listambiguous and automenu (I don't have
menucompletion set, so I presume, automenu is set by default?) It looks to
me, that

first TAB inserts prefix
second TAB shows list (due to autolist? listambiguous? or both?)
third TAB starts menu (due to automenu?)

I just tested (_complete:_match), and am still confused :-)

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!

It is the difference in cursor placement that confuses me. I would not
expect any difference except in when list is shown/menu is started. I think,
that probably a description how all these options work together would be
really useful in completion manual.

Do I understand it correctly, that when compstate[insert] is set to a
number, menu completion is started immediately? (BTW, manuals are not
updated) Is it possible to completely emulate builtin code by testing
compstate[insert] for menu, ambiguous values? And probably take in account
the compstate[list] value? But to do this, one needs the clear picture, how
they all play together ...

cheers

/andrej