_match and auto menu with multipath again

_match and auto menu with multipath again

[Andrej Borsenkow]

As I can recall, _match automatically starts menu completion (if more than one
choice is present). I won't argue that (after all, there is no place where I can
type in next char :-), but I still find the current way pretty confusing:

bor@itsrm2:~%> compconf -L
compconf correct_accept='2n'
compconf match_original='yes'
compconf completer='_complete:_match'
compconf dumpfile='/home/bor/.zcompdump'
compconf correct_prompt='correct to:'
bor@itsrm2:~%> l /a/p/u/z/z*22*<TAB>
bor@itsrm2:~%> l /archive/pub/unix/zip/z*22*
zip/  zsh/

Note again, that menu is started for some middle path - without *any* visible
feedback for user (that is, I have no idea what is being completed). Even worse,
repeatedly typing TAB cycles through ``zip'' and ``zsh'', leaving no way to
select one (yes, I know - 'cursor-left,cursor-right' etc, but they are not
*natural* way). This switch to menu is very unexpected and will confuse many
users.

That was mostly a reason, why I requested cursor be placed on a word part that
is being completed. How hard is it to simply start normal completion? What I
mean, is:

bor@itsrm2:~%> l /a/p/u/z/z*22*<TAB>
bor@itsrm2:~%> l /archive/pub/unix/z/z*22*
zip/ zsh/                           ^ cursor here
and after this part is done, simply start normal completion for the next
ambiguous part?

I don't insist on it being default, but as an option?

/andrej

RE: _match and auto menu with multipath again

[Andrej Borsenkow]

>
> I wasn't completely sure what behavior you want in which case, so I
> just added two new configuration keys:
>
>   path_cursor
>     if this is set to a non-empty string, the cursor will be placed
>     after the ambiguous pathname component even if menucompletion is
>     used
>
>   match_insert
>     if this is set to anything starting with `unambig', menucompletion
>     is only started (by the _match completer, obviously) if no
>     unambiguous string that is at least as long as the original string
>     could be generated
>
> Does any of these do what you want? Note that setting `match_insert=unambig'
> may sometimes remove a short pattern if enough components further up
> the path were expanded. This is a bit ugly, yes, but I can't think of
> an easy way to find out where that precious pattern is which one might
> want to have preserved.
>

Wow! I personally love the latter:

bor@itsrm2:~%> compconf match_insert=unambig
bor@itsrm2:~%> l /a/p/u/z/z*22*<TAB>
bor@itsrm2:~%> l /archive/pub/unix/z/z*22*
zip/  zsh/                          ^ cursor here

and now I can complete ambiguous path component and hit TAB again.

Now, does it look sensible to others? If it is more natural, may be, we should
make it default?

/andrej

Thank you, Sven!

Re: _match and auto menu with multipath again

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> bor@itsrm2:~%> l /a/p/u/z/z*22*<TAB>
> bor@itsrm2:~%> l /archive/pub/unix/zip/z*22*
> zip/  zsh/
> 
> Note again, that menu is started for some middle path - without *any* visible
> feedback for user (that is, I have no idea what is being completed). Even worse,
> repeatedly typing TAB cycles through ``zip'' and ``zsh'', leaving no way to
> select one (yes, I know - 'cursor-left,cursor-right' etc, but they are not
> *natural* way). This switch to menu is very unexpected and will confuse many
> users.
> 
> That was mostly a reason, why I requested cursor be placed on a word part that
> is being completed. How hard is it to simply start normal completion? What I
> mean, is:
> 
> bor@itsrm2:~%> l /a/p/u/z/z*22*<TAB>
> bor@itsrm2:~%> l /archive/pub/unix/z/z*22*
> zip/ zsh/                           ^ cursor here
> and after this part is done, simply start normal completion for the next
> ambiguous part?
> 
> I don't insist on it being default, but as an option?

I wasn't completely sure what behavior you want in which case, so I
just added two new configuration keys:

  path_cursor
    if this is set to a non-empty string, the cursor will be placed
    after the ambiguous pathname component even if menucompletion is
    used

  match_insert
    if this is set to anything starting with `unambig', menucompletion 
    is only started (by the _match completer, obviously) if no
    unambiguous string that is at least as long as the original string 
    could be generated

Does any of these do what you want? Note that setting `match_insert=unambig'
may sometimes remove a short pattern if enough components further up
the path were expanded. This is a bit ugly, yes, but I can't think of
an easy way to find out where that precious pattern is which one might 
want to have preserved.

Bye
 Sven

diff -u -r oc/Core/_match Completion/Core/_match
--- oc/Core/_match	Thu Jun 17 09:24:57 1999
+++ Completion/Core/_match	Thu Jun 17 10:22:43 1999
@@ -9,7 +9,7 @@
 # expand-or-complete function because otherwise the pattern will
 # be expanded using globbing.
 #
-# Configuration key used:
+# Configuration keys used:
 #
 #  match_original
 #    If this is set to a `only', pattern matching will only be tried
@@ -18,6 +18,11 @@
 #    no completions, matching will be tried again with a `*' inserted
 #    at the cursor position. If this key is not set or set to an empty
 #    string, matching will only be attempted with the `*' inserted.
+#
+#  match_insert
+#    If this is set to a string starting with `unambig', menucompletion
+#    will only be turned on if no unambiguous string could be built
+#    that is at least as long as the original string.
 
 local tmp opm="$compstate[pattern_match]" ret=0
 
@@ -37,7 +42,12 @@
   compstate[pattern_match]="$opm"
   compstate[matcher]="$compstate[total_matchers]"
 
-  (( ret )) && return 0
+  if (( ret )); then
+    [[ "$compconfig[match_insert]" = unambig* &&
+       $#compstate[unambiguous] -ge ${#:-${PREFIX}${SUFFIX}} ]] && 
+        compstate[pattern_insert]=unambiguous
+    return 0
+  fi
 fi
 
 # No completion with inserting `*'?
@@ -49,5 +59,11 @@
 _complete && ret=1
 compstate[pattern_match]="$opm"
 compstate[matcher]="$compstate[total_matchers]"
+
+if (( ! ret )); then
+  [[ "$compconfig[match_insert]" = unambig* &&
+     $#compstate[unambiguous] -ge ${#:-${PREFIX}${SUFFIX}} ]] && 
+      compstate[pattern_insert]=unambiguous
+fi
 
 return 1-ret
diff -u -r oc/Core/_path_files Completion/Core/_path_files
--- oc/Core/_path_files	Thu Jun 17 09:24:56 1999
+++ Completion/Core/_path_files	Thu Jun 17 10:24:07 1999
@@ -11,12 +11,17 @@
 # with one of the suffixes thus given are treated like files with one
 # of the suffixes in the `fignore' array in normal completion.
 #
-# This function supports one configuration key:
+# This function supports two configuration keys:
 #
 #  path_expand
 #    If this is set to a non-empty string, the partially typed path
 #    from the line will be expanded as far as possible even if trailing
 #    pathname components can not be completed.
+#
+#  path_cursor
+#    If this is set to an non-empty string, the cursor will be placed
+#    in the path after the ambiguous pathname component even when using
+#    menucompletion.
 
 local linepath realpath donepath prepath testpath exppath
 local tmp1 tmp2 tmp3 tmp4 i orig pre suf tpre tsuf
@@ -304,10 +309,11 @@
       # it as far as possible.
 
       if [[ -n $menu ]]; then
+        [[ -n "$compconfig[path_cursor]" ]] && compstate[to_end]=''
         if [[ "$tmp3" = */* ]]; then
 	  compadd -Uf -p "$linepath$testpath" -s "/${tmp3#*/}" \
 	          -W "$prepath$realpath$testpath" "$ignore[@]" \
-		  "$addpfx[@]" "$addsfx[@]" "$remsfx[@]" \
+		  "$addpfx[@]" "$addsfx[@]" "$remsfx[@]" -M 'r:|/=* r:|=*' \
 		  "$group[@]" "$expl[@]" -i "$IPREFIX" -I "$ISUFFIX" \
 		  - "${(@)tmp1%%/*}"
 	else
diff -u od/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- od/Zsh/compsys.yo	Thu Jun 17 09:24:40 1999
+++ Doc/Zsh/compsys.yo	Thu Jun 17 10:28:13 1999
@@ -467,6 +467,12 @@
 `tt(*)' will be inserted. If tt(match_original) has any other non-empty
 string as its value, this completer will first try to generate matches
 without, then with a `tt(*)' inserted at the cursor position.
+
+The generated matches will be offered in a menucompletion unless the
+tt(match_insert) configuration key is set to a string starting with
+`tt(unambig)'. In this case menucompletion will only be started if no
+unambiguous string could be generated that is at least as long as the
+original string.
 )
 item(tt(_expand))(
 This completer function does not really do completion, but instead
@@ -700,10 +706,13 @@
 `tt(-S)', `tt(-q)', `tt(-r)', and `tt(-R)' options from the
 tt(compadd) builtin.
 
-Finally, the tt(_path_files) function supports one configuration key:
-tt(path_expand). If this is set to any non-empty string, the partially
+Finally, the tt(_path_files) function supports two configuration keys.
+If tt(path_expand) is set to any non-empty string, the partially
 typed path from the line will be expanded as far as possible even if
-trailing pathname components can not be completed.
+trailing pathname components can not be completed. And if
+tt(path_cursor) is set to a non-empty string, the cursor will be left
+after the first ambiguous pathname component even when menucompletion
+is used.
 )
 item(tt(_parameters))(
 This should be used to complete parameter names if you need some of the

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