Re: _match and auto menu with multipath again

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

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!

pws-23: RE: _match and auto menu with multipath again

[Andrej Borsenkow]

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


Thinking more and more about it: what is the reason for _match to automatically
start menu completion at all (apart from compatibility with old zsh, that can be
preserved with configuration key). Think about it:

1. We complete /u/l/s/z/f -> /usr/local/share/zsh/functions
This is actually the same as if we completed /u*/l*/s*/z*/f* - and is
interpreted and implemented this way. What happens is, that unambiguous prefix
is replaced and first ambiguous part is replaced with the largest common prefix;
remaining parts retain there (implicit) glob pattern. That is, we get something
like

/usr/local/s/z*/f*
share status ...

how does it differ from

2. We complete /u/l/s/z/f*s -> /usr/local/share/zsh/functions ?
In no way, except, that we know better some patterns (more than only initial
character) and thus are able to reduce possible matches. Note, that patterns are
often longer than most common prefix - typing /u/l/lib*X* will typically leave
me with just 'lib' prefix.

So, I think, that either match_insert should be changed to always insert prefix
(irrespectively of length) or we need additional config key to force it.

And about cutrrent behaviour:

compconf correct_accept='2n'
compconf match_original='yes'
compconf completer='_complete:_match'
compconf dumpfile='/home/bor/.zcompdump'
compconf path_cursor='yes'
compconf match_insert='unambig'
compconf correct_prompt='correct to:'
bor@itsrm2:~%> l /u/l/lib*X*<TAB>
bor@itsrm2:~%> l /usr/lib/lib*X*
lib/     lib64s/         ^ cursor here

That is correct and is what I expected. But simply pressing TAB once more
results in

bor@itsrm2:~%> l /usr/lib/libX11.a
lib/     lib64s/

While if I press any cursor movement key and then TAB I get

bor@itsrm2:~%> l /usr/lib/lib*X*
lib/     lib64s/          ^ cursor here (after cursor-right)
bor@itsrm2:~%> l /usr/lib/libX11.a
libX11.a@           libXaw.so.6.1@      libXmSni.so.3.0@    libXpm.so.3.4@
libX11.so@          libXdUtils.so.3.1@  libXmu.a@           libXpm.so.4.6@
.................... (long list),
or if I explicitly enter '6'

bor@itsrm2:~%> l /usr/lib/lib*X*
lib/     lib64s/         ^ cursor here
bor@itsrm2:~%> l /usr/lib6/lib*X*
lib/     lib64s/          ^ cursor here and TAB
bor@itsrm2:~%> l /usr/lib64s/libX11.a
libX11.a@          libXaw.so.6.1@     libXmu.so@         libXpm.so@
libX11.so@         libXdmcp.a@        libXmu.so.6.0@     libXpm.so.3.4@
........................

Looks like a problem with list redisplay. Completion code thinks, it has still
old valid list. And this also illustrates my point - in this case I do not want
menu completion - I just want list to be dislpayed. But, unfortunatley,
length(lib) < length(lib*X*) :-(

/andrej

Just in case:
6731, 6732 applied

Re: pws-23: RE: _match and auto menu with multipath again

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> Looks like a problem with list redisplay. Completion code thinks, it has still
> old valid list.

I needed some time to play with configuration keys until I could
reproduce this...
When switching to menucompletion it sometimes didn't show a newly
generated list because it though it had just started automenu using
the old list of matches.

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Mon Jun 21 12:49:49 1999
+++ Src/Zle/zle_tricky.c	Mon Jun 21 14:32:17 1999
@@ -7486,7 +7486,7 @@
      * if it is needed.                                                     */
     if (isset(LISTBEEP))
 	feep();
-    if (uselist && usemenu != 2 &&
+    if (uselist && (usemenu != 2 || (!showinglist && !oldlist)) &&
 	(!showinglist || (usemenu == 3 && !oldlist)) &&
 	(smatches >= 2 || (compforcelist && *compforcelist)))
 	showinglist = -2;

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

Re: pws-23: RE: _match and auto menu with multipath again

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > 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.
> 
> Thinking more and more about it: what is the reason for _match to automatically
> start menu completion at all (apart from compatibility with old zsh, that can be
> preserved with configuration key).

Because a pattern may match anything -- we can not be sure that all
results have some common prefix (or other common string).

> Think about it:
> 
> 1. We complete /u/l/s/z/f -> /usr/local/share/zsh/functions
> This is actually the same as if we completed /u*/l*/s*/z*/f* - and is
> interpreted and implemented this way.

Not really: every path component is matched using normal completion
matching rules. Nowadays we don't use patterns like `/u*/l*' any more.

> What happens is, that unambiguous prefix
> is replaced and first ambiguous part is replaced with the largest common prefix;
> remaining parts retain there (implicit) glob pattern. That is, we get something
> like
> 
> /usr/local/s/z*/f*
> share status ...

No, the code expands the remaining pathname components, too (if possible).

> how does it differ from
> 
> 2. We complete /u/l/s/z/f*s -> /usr/local/share/zsh/functions ?
> In no way, except, that we know better some patterns (more than only initial
> character) and thus are able to reduce possible matches.

See above, and: for the completion code there is a big difference
between working on a pattern and working on a normal string. Only in
the latter case do we use the match specs (-M) -- and I really think
it should be so because if you type a pattern, you probably know
better what you want than the completion code.

> Note, that patterns are
> often longer than most common prefix - typing /u/l/lib*X* will typically leave
> me with just 'lib' prefix.

I know, that's why I pointed out that the result is sometimes ugly.

> So, I think, that either match_insert should be changed to always insert prefix
> (irrespectively of length) or we need additional config key to force it.

Feel free to implement something in _match that preserves the pattern
parts of a pathname. Dunno when I find time for this... don't hold
your breath.

> And about cutrrent behaviour:
> 
> compconf correct_accept='2n'
> compconf match_original='yes'
> compconf completer='_complete:_match'
> compconf dumpfile='/home/bor/.zcompdump'
> compconf path_cursor='yes'
> compconf match_insert='unambig'
> compconf correct_prompt='correct to:'
> bor@itsrm2:~%> l /u/l/lib*X*<TAB>
> bor@itsrm2:~%> l /usr/lib/lib*X*
> lib/     lib64s/         ^ cursor here
> 
> That is correct and is what I expected. But simply pressing TAB once more
> results in
> 
> bor@itsrm2:~%> l /usr/lib/libX11.a
> lib/     lib64s/
> 
> While if I press any cursor movement key and then TAB I get
> 
> bor@itsrm2:~%> l /usr/lib/lib*X*
> lib/     lib64s/          ^ cursor here (after cursor-right)
> bor@itsrm2:~%> l /usr/lib/libX11.a
> libX11.a@           libXaw.so.6.1@      libXmSni.so.3.0@    libXpm.so.3.4@
> libX11.so@          libXdUtils.so.3.1@  libXmu.a@           libXpm.so.4.6@
> .................... (long list),

Completion was started and _path_files skipped over pathname
components that really exist, matches are the files matching lib*X* in 
/usr/lib. (The list is what you have in /usr/lib, right? If so, then
this is correct behavior.)

> or if I explicitly enter '6'
> 
> bor@itsrm2:~%> l /usr/lib/lib*X*
> lib/     lib64s/         ^ cursor here
> bor@itsrm2:~%> l /usr/lib6/lib*X*
> lib/     lib64s/          ^ cursor here and TAB
> bor@itsrm2:~%> l /usr/lib64s/libX11.a
> libX11.a@          libXaw.so.6.1@     libXmu.so@         libXpm.so@
> libX11.so@         libXdmcp.a@        libXmu.so.6.0@     libXpm.so.3.4@
> ........................

If these are the files in /usr/lib642 matching lib*X*, then this is
correct again (see above).

If not, then I can't reproduce this bug. But maybe I understood you
completely wrong?

Bye
 Sven


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