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

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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