Re: File completion with **/ (with solution)

Re: File completion with **/ (with solution)

[Daniel Shahaf]

Bart Schaefer wrote on Tue, Sep 20, 2016 at 17:56:23 -0700:
>   _glob_expand() { reply=( $~1* ) }
>   zstyle :completion::user-expand:: user-expand _glob_expand
>   zstyle :completion::user-expand:: tag-order expansions all-expansions
>   zstyle ':completion:*' completer _expand _complete _match _user_expand
> 
> Daniel, this might be the "better answer" to your _match question, too.

Right: I could use _user_expand instead of _expand in my completer
style, and implement a policy such as
.
    1. Try _expand if $condition
    2. Try _match
    3. Try _expand if not $condition
.
with $condition being the *[*][*]* pattern from the _match thread.

> The other thing it might be useful to call out in the doc is to note that
> because _user_expand is called AS a completer, it has access to more of
> the zstyle $context when it is called than when the "completer" style is
> looked up.  This could be handy when deciding what to assign to $reply.

I don't see that additional context: if I define _f as a completer
function, then it's called with curcontext=:f::.

Thanks again for all the investigations.  I've switched to your 'zstyle
-e' solution since this way I don't have to munge $curcontext in my
wrapper function.

Cheers,

Daniel

Re: File completion with **/ (with solution)

[Bart Schaefer]

On Sep 20, 10:32pm, Bart Schaefer wrote:
}
} There's a typo above; should be
}    zstyle :completion::user-expand::: tag-order expansions all-expansions
} 
} I'm not sure why there are fewer colons in user-expand than in tag-order.
} I think there's a similar typo in _user_expand looking up that style.

There's an additional bug in _user_expand that breaks tag-order when
there is exactly a single match.  I think the -gt test (see diff) was
expecting $exp[1] to be the original input pattern and wanted to skip
that, or something.

I'll apply the patch below to make the above tag-order work in zsh 5.3,
but for all prior versions you'll have to do:

zstyle :completion::user-expand::: tag-order 'expansions all-expansions'


diff --git a/Completion/Base/Completer/_user_expand b/Completion/Base/Completer/_user_expand
index cf3d172..066e2e8 100644
--- a/Completion/Base/Completer/_user_expand
+++ b/Completion/Base/Completer/_user_expand
@@ -27,7 +27,7 @@ exp=("$word")
 
 # Now look for user completions.
 
-zstyle -a ":completion:${curcontext}" user-expand specs || return 1
+zstyle -a ":completion:${curcontext}:" user-expand specs || return 1
 
 for spec in $specs; do
   REPLY=
@@ -95,7 +95,7 @@ if [[ -z "$compstate[insert]" ]] ;then
 else
   _tags all-expansions expansions original
 
-  if [[ $#exp -gt 1 ]] && _requested expansions; then
+  if [[ $#exp -ge 1 ]] && _requested expansions; then
     local i j normal space dir
 
     if [[ "$sort" = menu ]]; then

Re: File completion with **/ (with solution)

[Bart Schaefer]

On Sep 20,  5:56pm, Bart Schaefer wrote:
}
}   _glob_expand() { reply=( $~1* ) }
}   zstyle :completion::user-expand:: user-expand _glob_expand
}   zstyle :completion::user-expand:: tag-order expansions all-expansions

There's a typo above; should be
   zstyle :completion::user-expand::: tag-order expansions all-expansions

I'm not sure why there are fewer colons in user-expand than in tag-order.
I think there's a similar typo in _user_expand looking up that style.

}   zstyle ':completion:*' completer _expand _complete _match _user_expand

File completion with **/ (with solution)

[Bart Schaefer]

This started out as an email to ponder/grumble about why _match can't
resolve a recursive glob.  Along the way I discovered a way to accomplish
what I wanted ... but I'll leave the leading expository stuff for context,
having taken the time to write it.

Using the _match completer, I can do (in the zsh source tree)

% ls C*/*/*/_main<TAB>

to get the expected result of

% ls Completion/Base/Core/_main_complete

On the other hand, if I do

% ls C*/**/_main<TAB>

I get no result.

If I have the _expand completer and manually append a "*" before hitting
TAB, I also get the desired result.  Or if I have _complete and do

ls C///_main<TAB>

then _path_files does magic for me, but I have to use the exact correct
number of slashes, which is precisely what I want to avoid doing.

The "problem" with _match is that it doesn't change the way that possible
completions are generated; it only changes the way the word on the line
is compared to the possible completions to select the candidate matches.

It was at this point that I re-read the doc for the _user_expand completer
for the first time in years.

_user_expand looks up the array-valued style "user-expand" and steps
through the array until one of the elements yields at least one possible
completion, by assigning it to the $reply array.  You can read the doc
to find out what the elements look like.  There are several things about
_user_expand that could be improved with features of more recent zsh,
and the doc doesn't cover all the other styles it recognized / tags it
uses, so that needs update too.  However, it's perfect for solving the
problem I just described:

  _glob_expand() { reply=( $~1* ) }
  zstyle :completion::user-expand:: user-expand _glob_expand
  zstyle :completion::user-expand:: tag-order expansions all-expansions
  zstyle ':completion:*' completer _expand _complete _match _user_expand

The other thing it might be useful to call out in the doc is to note that
because _user_expand is called AS a completer, it has access to more of
the zstyle $context when it is called than when the "completer" style is
looked up.  This could be handy when deciding what to assign to $reply.

It would mostly work to include other completers / completion functions
as elements of the user-expand array, but note that they'll ALL be tried
(rather than only tried until at least one finds a match), because the
functions normally won't assign to $reply and that is currently the only
way to stop walking the elements.

Daniel, this might be the "better answer" to your _match question, too.