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

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

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> 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.

No, three. What irritates you here is that the unambiguous string
inserted on the first TAB is the same as the first match inserted at
the third TAB. Try:

  % mkdir foo; touch foo/foo{1,2,3};cd foo
  % ls f<TAB><TAB><TAB>

Here you get `foo' on the first TAB, the list on the second, and
`foo1' on the third (starting menucompletion).

Ok?

[ Rest of the mail deleted, let's start from scratch. ]

Think about `listambiguous' as an option delaying normal processing
for one TAB.

Now, without `listambiguous', but with `automenu' set it goes like this:

1) First TAB, completions are generated, more than one match, the code 
   inserts the unambiguous part and (if `autolist' is set) shows the
   list. If `automenu' is set, it sets everything up so that
   menucompletion is started on the next TAB. And since normal
   completion is done here, the cursor is moved into the word.
2) Second TAB, directly after the previous one. Menucompletion is
   started due to the setup from the first TAB, *no* completions are
   created, it just uses the old list. It knows the position
   the cursor was at (well, not actually the position, only if it was
   at the end of the whole word) when things were set up for
   `automenu'. In this case this was the first TAB, where the cursor
   was at the end of the word (remember: it knows about the position
   of the cursor *when completion was started* -- and cares little
   about the position of the cursor after the unambiguous stuff has
   been inserted because we once decided that moving the cursor to the 
   end is a good thing for menucompletion, but not for normal
   completion).
   Well, with all that it moves the cursor to the end when
   menucompleting because it was at the end when the completion was
   done that made `automenu' start menucompletion on the next TAB.

Ok. With `listambiguous' set:

1) First TAB, completions are generated, more than one match, the
   unambiguous string is inserted. This time it sees that
   `listambiguous' is set and delays everything (both listing and
   menucompletion, trying to make everything after the next TAB *look* 
   like the first case above).
2) Second TAB, completions are generated (for the second time, this is
   the important bit). This time the cursor was in the middle of the
   word when the whole comlpetion code was run.
   Since it can't build an unambiguous string this time (more exactly:
   no unambiguous string different from what's on the line),
   `listambiguous' is ignored and the list is shown (with
   `autolist'). And then the code behaves as on the first TAB in the
   first case, setting everything up for `automenu'. But here the
   previous TAB left the cursor in the middle of the word and that is
   remmebered.
3) Third TAB, menucompletion is immediatly started. Remembering that
   the cursor was in the middle of the word before the second TAB, it
   leaves it there.

That's it. When we added the `bashautolist' option and I did the
clean-ups in `do_ambiguous()' I mentioned that we can do this only
easily in the code by calling the completion code again (sorry, for
the strange wording, but whenever I talk about completion, I'm
thinking in terms of the code, I hope the stuff above made this
clearer). And calling it twice -- more precicesly: treating everything 
*after* the first TAB with `listambiguous' *like* the first TAB with
`listambiguous' unset is what makes this look different from the other 
cases you mentioned. But it isn't, you just have to remember that with 
`listambiguous' set the first TAB doesn't care about `automenu' and
happily does normal completion. With that the rest follows naturally.

Finally, your request for getting this cursor-left-in-word behavior
always: I've added the `compstate[to_end]' key just for this. If you
stick a `compstate[to_end]=single' in you `_main_complete' you'll get
what you want. I didn't add an option for this mainly because I'm
reluctant to add options (remembering times when we had many people
here complaining about too many options being added).


So question to everyone: is it important enough to add an option, say
  `menu_in_word', that makes the cursor be left inside the word when
  menucompletion is used and the cursor was *not* already in the word
  before menucompletion was started?

I may also say (again) that this is a relatively new problem because
previously we didn't have normal completion move the cursor somewhere
inside the word where it hadn't been before -- and not all these
matchers, functions, and stuff that make this useful.

To add or not to add...

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

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

[Bart Schaefer]

On Mar 30,  2:52pm, Sven Wischnowsky wrote:
} Subject: RE: PATCH: was RE: PATCH: old lists compstate
}
} So question to everyone: is it important enough to add an option, say
}   `menu_in_word', that makes the cursor be left inside the word when
}   menucompletion is used and the cursor was *not* already in the word
}   before menucompletion was started?

I think moving the cursor into the word and leaving it there is only
useful if complete_in_word is modified (possibly by the same option that
moves the cursor) to work more like some emacs completion modes do; to
wit, complete to the left (ignoring the right), and if that produces an
exact match, then move to the right one unit (to the next slash, or
the next underscore or hyphen or dot or whatever for part completion)
and try again.

I'm probably not describing that fully, but you get the idea.  I can't
otherwise think of a case where it's helpful to leave the cursor to the
left of where it started.

On the other hand, treating the cursor motion the way that autoremoval
is treated might be kind of cool; that is, move it to the middle of the
word, but if any of the range of characters that trigger autoremoval is
typed, the cursor jumps back to where it was before completion started.
(I have no idea how that would work in practice; if it went wrong, it
would probably go wrong in a big way, so ...)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

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

[Andrej Borsenkow]

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

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

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > > I just tested (_complete:_match), and am still confused :-)
>                    ^^^^^^^^^^^^^^^^^
> I do *not* use _menu in this case

Sorry, your speaking about `_menu' confused me...

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). 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. 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). 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...

Now try `setopt alwaystoend'...

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

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

[Andrej Borsenkow]

>
> > I just tested (_complete:_match), and am still confused :-)
                   ^^^^^^^^^^^^^^^^^
I do *not* use _menu in this case
>
> All this should become clear when you remember what I said above:
> `_menu' does *not* start menucompletion (in the C-code sense). So the
> C-code uses all the options as for normal completion.
>

All these examples are for "normal C completion" with compconf
completer=_complete:_match. So again - why is the third case different?

(while you are still here :-)

/andrej

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

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > > 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.

(More precisely, it cycles through all ambiguous components, right?.)

The problem with all this is that setting `compstate[insert]' to a
number does *not* start menucompletion. Also, the rest of the example
functions don't know about this yet and that makes `_path_files'
behave as for normal completion in this case. The patch below changes
this (and fixes a type in `_cd', and adds the manual which I forgot to 
include, sorry).

I was first thinking about whether setting `compstate[insert]' to a
number should start menucompletion, but decided against it because it
would be much less powerful then.

> > 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?)

Shown because of autolist. Shown only on the second TAB because of
listambiguous. (And all this is described quite verbosely in the
manual.)

> third TAB starts menu (due to automenu?)

Yes, automenu. And again: on the third TAB due to lisambiguous.

> 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.

All this should become clear when you remember what I said above:
`_menu' does *not* start menucompletion (in the C-code sense). So the
C-code uses all the options as for normal completion.

> 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 ...

It should be possible to emulate everything in shell code. But `_menu' 
was intended as a very simple (and slightly silly) example how to
start with implementing menucompletion in shell code. Since I don't
use menucompletion and don't like it I'm not really planning to
implement more of this in shell code (we would also need `_revers_menu',
`_accept_and_men' and so on -- all of these should be possible
already).

Also, please remember that I said that the `old_*' keys are very
experimental. And if even I say this...

MAybe you can just play with all this some more, collect ideas and
sometime let us know about it. I'm not planning to do more this week
and next week I'll be away, so you have some time ;-)

Btw. the changes to `_path_files' and `_multi_parts' might eventually
disappear again, because I don't want a `$compstate[insert]' value of
`[0-9]*' to stand for menucompletion. In a better implementation,
`_menu' would set some variable that is tested by the functions that
show special behavior for menucompletion.

Bye
 Sven

diff -u od/Zsh/compwid.yo Doc/Zsh/compwid.yo
--- od/Zsh/compwid.yo	Fri Mar 26 18:57:26 1999
+++ Doc/Zsh/compwid.yo	Sun Mar 28 16:40:51 1999
@@ -205,6 +205,20 @@
 inserted or if the first match will be inserted and menu completion
 will be started (due to tt(MENU_COMPLETE) or tt(AUTO_MENU) being set), 
 respectively.
+
+On exit it may be set to any of the values above with the obvious
+result or to a number or a string of the form
+`var(group):var(match)'. If it is set to a number the match whose
+number is given will be inserted in the command line. A string like
+`tt(2:4)' specifies which match from which group should be
+inserted. In this example the fourth match of the second group is
+inserted. All groups and matches are number from one upwards. In the
+value of this key, negative numbers count backward from the last match 
+or group (with `tt(-1)' selecting the last match or group) and values
+out of the range from one to the number of matches or groups are
+wrapped around (so that a value of zero selects the last match and a
+value equal to the number of matches or groups plus one selects the
+first one).
 )
 item(tt(to_end))(
 On entry to the completion widget this is set to tt(single) if the
@@ -225,6 +239,28 @@
 and any other value says to move the cursor to the end when a full
 match is inserted (a single match or the first match when using
 menucompletion).
+)
+item(tt(old_list))(
+This is set to tt(yes) if there is still a valid list of completions
+from a previous completion at the time the widget is invoked. Such a
+list exists if it was generated by the previous key press. If the list 
+is also shown on the screen, the value of this key is tt(shown).
+
+After the widget has exited the value of this key is only used if it
+was set to tt(keep). In this case, the completion code will continue
+to use this old list. If the widget generated new matches, they will
+not be used.
+)
+item(tt(old_insert))(
+On entry to the widget this will be set to the number of the match of
+an old list of completions that is currently inserted in the command
+line. If no match has been inserted, this is unset.
+
+As with tt(old_list), the value of this key will only be used if it is 
+the string tt(keep). If it was set to this value by the widget and
+there was an old match inserted in the line, this match will be kept
+and if the value of the tt(insert) key says that another match should
+be inserted, this will be inserted after the old one.
 )
 item(tt(exact))(
 This is set to tt(accept) if an exact match would be accepted by the
diff -u -r oc/Builtins/_cd Completion/Builtins/_cd
--- oc/Builtins/_cd	Mon Mar 29 11:48:49 1999
+++ Completion/Builtins/_cd	Tue Mar 30 11:54:43 1999
@@ -55,7 +55,7 @@
   list=(${list%%[ 	]*})
   compgen -y '$lines' -Q -k list && ret=0
   [[ -z $compstate[list] ]] && compstate[list]=list && ret=0
-  [[ -n $compstate[insert] ]] && compstat[insert]=menu && ret=0
+  [[ -n $compstate[insert] ]] && compstate[insert]=menu && ret=0
 
   return ret
 elif [[ $PREFIX != (\~|/|./|../)* && $#cdpath -ne 0 ]]; then
diff -u -r oc/Core/_multi_parts Completion/Core/_multi_parts
--- oc/Core/_multi_parts	Mon Mar 29 15:46:12 1999
+++ Completion/Core/_multi_parts	Tue Mar 30 11:53:32 1999
@@ -55,7 +55,7 @@
 fi
 orig="${PREFIX}${SUFFIX}"
 
-[[ $compstate[insert] = *menu || -n "$_comp_correct" ||
+[[ $compstate[insert] = (*menu|[0-9]*) || -n "$_comp_correct" ||
    ( $#compstate[pattern_match] -ne 0 &&
      "$orig" != "${orig:q}" ) ]] && menu=yes
 
diff -u -r oc/Core/_path_files Completion/Core/_path_files
--- oc/Core/_path_files	Mon Mar 29 15:46:13 1999
+++ Completion/Core/_path_files	Tue Mar 30 11:52:54 1999
@@ -123,7 +123,7 @@
 fi
 orig="${PREFIX}${SUFFIX}"
 
-[[ $compstate[insert] = *menu || -n "$_comp_correct" ||
+[[ $compstate[insert] = (*menu|[0-9]*) || -n "$_comp_correct" ||
    ( $#compstate[pattern_match] -ne 0 &&
      "${orig#\~}" != "${${orig#\~}:q}" ) ]] && menu=yes
 

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

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

[Andrej Borsenkow]

> > 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

PATCH: was RE: PATCH: old lists compstate

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > I've added a small example completer function `_menu' that may be put
> > before the normal `_complete' completer and that gives menucompletion
> > implemented fully in shell code (note that this does not work together
> > with normal menucompletion).
> 
> bor@itsrm2:~%> compconf
> correct_accept            2n
> match_original            yes
> completer                 _complete:_match
> dumpfile                  /home/bor/.zsh.d/Completion/Core/compinit.dump
> correct_prompt            correct to:
> 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?

> 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.

Also, I'd like to point out that I mentioned the (somewhat weird)
cursor-positioning `_menu' shows in the mail Andrej was replying to.

> BTW to the first example. I have these options:
> 
> noautolist            off
> bashautolist          off
> nolistambiguous       off
> 
> but list is shown only after the second TAB (as if bashautolist was set).
> I'd expect, that with autolist+listambiguous list were shown after the first
> TAB already. Actually, I think, it started with bashautolist option ... but
> as I used menu completion before ... :-)

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.

> And about compconf ... exaclty in the case above I missed something like
> 
> compconf -i _list completer (meaning insert _list to the element completer)
> or, at least,
> 
> compconf completer=_list:$(compconf -l completer)
> 
> or like. I mean, user probably should not see this array at all ...

I think he should. For exactly this reason I didn't make it start with 
an underscore -- with an underscore it would be as invisible as
`_comps' ;-)
Anyway, I don't like that `-i' option (inserted where? and not every
key is a list of words). But the patch at least adds the `-l' option,
which makes sense, I think.

> P.S. The same with zsh -f; fpath=(....); source ...; compconf
> completer=_menu:_complete:_match  But I get additional beep (I set nobeep
> normally).  And here list is shown immediately with the same options as
> above. wonders ...

Not for me. Unless I set menucomplete (which you haven't listed). And
with menucompletion there is no `unambiguous' string ever inserted.
The beep comes from `listbeep' being normally set, I think.

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Mon Mar 29 11:49:33 1999
+++ Src/Zle/zle_tricky.c	Tue Mar 30 10:15:53 1999
@@ -6877,7 +6877,7 @@
 	/* We are currently not in a menu-completion, *
 	 * so set the position variables.             */
 	menupos = wb;
-	menuwe = (movetoend >= 2 || (movetoend = 1 && !menucmp));
+	menuwe = (movetoend >= 2 || (movetoend == 1 && !menucmp));
 	menuend = we;
     }
     /* If we are already in a menu-completion or if we have done a *
@@ -6978,7 +6978,7 @@
     if (menuwe && m->ripre && isset(AUTOPARAMKEYS))
 	makeparamsuffix(((m->flags & CMF_PARBR) ? 1 : 0), menuinsc);
 
-    if (menucmp && !menuwe)
+    if ((menucmp && !menuwe) || !movetoend)
 	cs = menuend;
 }
 
diff -u oc/Core/compinit Completion/Core/compinit
--- oc/Core/compinit	Mon Mar 29 15:46:13 1999
+++ Completion/Core/compinit	Tue Mar 30 10:35:13 1999
@@ -219,18 +219,28 @@
 # Arguments may be `foo=bar' to set key `foo' to `bar' or `baz' to
 # set key `baz' to the empty string.
 # If no arguments are given, all configurations keys set are displayed.
+# With the option `-l' as the first argument, the other arguments are
+# taken to be key names and the values for theses keys are printed, one
+# per line.
 
 compconf() {
   local i
 
   if (( $# )); then
-    for i; do
-      if [[ "$i" = *\=* ]]; then
-        compconfig[${i%%\=*}]="${i#*\=}"
-      else
-        compconfig[$i]=''
-      fi
-    done
+    if [[ "$1" = -l ]]; then
+      shift
+      for i; do
+        print $compconfig[$i]
+      done
+    else
+      for i; do
+        if [[ "$i" = *\=* ]]; then
+          compconfig[${i%%\=*}]="${i#*\=}"
+        else
+          compconfig[$i]=''
+        fi
+      done
+    fi
   else
     for i in ${(k)compconfig}; do
       print ${(r:25:)i} $compconfig[$i]

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de