Using the same completion function for various commands

Using the same completion function for various commands

[Martin Richter]

Hello,

I'm searching the documentation for quite a while now but can't figure out how 
to do the following:

I wrote a completion function which resides somewhere in $fpath, let's call it 
_foo. But I don't want to have it applied on the command foo only. I want to use 
it on all commands matching a certain pattern, e.g. foo_1, foo_2, ... (or foo_* 
for short). Is it possible to define a context for this (like 
:completion::complete:foo_*::) and use zstyle to bind this completer to it? 
Unfortunately I couldn't figure out how. 
  zstyle "*" completer _<TAB>
only tells me about some built-ins.

Thank you very much and please forgive me in case I oversaw something obvious in 
the documentation.

Martin

Re: Using the same completion function for various commands

[Mikael Magnusson]

On 6 December 2010 15:12, Martin Richter
<mrichter@theory.phy.tu-dresden.de> wrote:
> Hello,
>
> I'm searching the documentation for quite a while now but can't figure out how
> to do the following:
>
> I wrote a completion function which resides somewhere in $fpath, let's call it
> _foo. But I don't want to have it applied on the command foo only. I want to use
> it on all commands matching a certain pattern, e.g. foo_1, foo_2, ... (or foo_*
> for short). Is it possible to define a context for this (like
> :completion::complete:foo_*::) and use zstyle to bind this completer to it?
> Unfortunately I couldn't figure out how.
>  zstyle "*" completer _<TAB>
> only tells me about some built-ins.
>
> Thank you very much and please forgive me in case I oversaw something obvious in
> the documentation.

       #compdef names... [ -[pP] patterns... [ -N names... ] ]
              The file will be made autoloadable and the function
defined in it will
              be called when completing names, each of which is either
the name of a
[...]
              If the #compdef line contains one of the options -p or
-P,  the  words
              following  are taken to be patterns.  The function will
be called when
              completion is attempted for a command or context that
matches  one  of
              the  patterns.   The options -p and -P are used to
specify patterns to

You can also do this in your .zshrc instead of in the completer if you
wish, just write
compdef _foo -p 'foo_*'

At least that's what the documentation says, it doesn't seem to work that well.

-- 
Mikael Magnusson

Re: Using the same completion function for various commands

[Jérémie Roquet]

Hi,

2010/12/6 Mikael Magnusson <mikachu@gmail.com>:
> You can also do this in your .zshrc instead of in the completer if you
> wish, just write
> compdef _foo -p 'foo_*'
>
> At least that's what the documentation says, it doesn't seem to work that well.

It works fine for me with 4.3.10, did I miss something?

Best regards,

-- 
Jérémie

Re: Using the same completion function for various commands

[Mikael Magnusson]

2010/12/6 Jérémie Roquet <arkanosis@gmail.com>:
> Hi,
>
> 2010/12/6 Mikael Magnusson <mikachu@gmail.com>:
>> You can also do this in your .zshrc instead of in the completer if you
>> wish, just write
>> compdef _foo -p 'foo_*'
>>
>> At least that's what the documentation says, it doesn't seem to work that well.
>
> It works fine for me with 4.3.10, did I miss something?

When i tried compdef _du -p foo_\*, i only got single-letter options completed.

-- 
Mikael Magnusson

Re: Using the same completion function for various commands

[Peter Stephenson]

On Mon, 6 Dec 2010 16:03:51 +0100
Mikael Magnusson <mikachu@gmail.com> wrote:

> 2010/12/6 Jérémie Roquet <arkanosis@gmail.com>:
> > Hi,
> >
> > 2010/12/6 Mikael Magnusson <mikachu@gmail.com>:
> >> You can also do this in your .zshrc instead of in the completer if
> >> you wish, just write
> >> compdef _foo -p 'foo_*'
> >>
> >> At least that's what the documentation says, it doesn't seem to
> >> work that well.
> >
> > It works fine for me with 4.3.10, did I miss something?
> 
> When i tried compdef _du -p foo_\*, i only got single-letter options
> completed.
> 

That means it's working perfectly.  It's hitting this line at the top of
_du

  _pick_variant gnu=Free\ Soft unix --version /dummy/no-such-file

and deciding, quite reasonably in my opinion, that foo_\* is not a GNU
variant of du.  So it's going to the other branch, where the options are
simpler.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Using the same completion function for various commands

[Mikael Magnusson]

On 6 December 2010 16:11, Peter Stephenson <Peter.Stephenson@csr.com> wrote:
> On Mon, 6 Dec 2010 16:03:51 +0100
> Mikael Magnusson <mikachu@gmail.com> wrote:
>
>> 2010/12/6 Jérémie Roquet <arkanosis@gmail.com>:
>> > Hi,
>> >
>> > 2010/12/6 Mikael Magnusson <mikachu@gmail.com>:
>> >> You can also do this in your .zshrc instead of in the completer if
>> >> you wish, just write
>> >> compdef _foo -p 'foo_*'
>> >>
>> >> At least that's what the documentation says, it doesn't seem to
>> >> work that well.
>> >
>> > It works fine for me with 4.3.10, did I miss something?
>>
>> When i tried compdef _du -p foo_\*, i only got single-letter options
>> completed.
>>
>
> That means it's working perfectly.  It's hitting this line at the top of
> _du
>
>  _pick_variant gnu=Free\ Soft unix --version /dummy/no-such-file
>
> and deciding, quite reasonably in my opinion, that foo_\* is not a GNU
> variant of du.  So it's going to the other branch, where the options are
> simpler.

Ah, er, right. But. Is there any way to combine -p and saying foo=du ?
When I tried compdef _du -p 'foo_*=du' nothing happened.

-- 
Mikael Magnusson

Re: Using the same completion function for various commands

[Peter Stephenson]

On Mon, 6 Dec 2010 16:18:47 +0100
Mikael Magnusson <mikachu@gmail.com> wrote:
> Ah, er, right. But. Is there any way to combine -p and saying foo=du ?
> When I tried compdef _du -p 'foo_*=du' nothing happened.

The current syntax isn't really powerful enough for that.  The
"foo_*=du" gets stored in _patcomps and then gets compared against the
word on the command line.  You'd need to put foo_* in the key and
squirrel the "=du" away somewhere else.

You could do it by (gasp) hacking the value, for example.

(I'm surprised we don't already sanitise the option settings within
compdef, seeing as you can call it from anywhere.  I suppose we've
got away with it because most people just have it running implicitly
from within compinit.)

Index: Completion/compinit
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/compinit,v
retrieving revision 1.25
diff -p -u -r1.25 compinit
--- Completion/compinit	8 Feb 2010 11:53:35 -0000	1.25
+++ Completion/compinit	6 Dec 2010 16:06:47 -0000
@@ -230,6 +230,10 @@ comppostfuncs=()
 
 compdef() {
   local opt autol type func delete new i ret=0 cmd svc
+  local -a match mbegin mend
+
+  emulate -L zsh
+  setopt extendedglob
 
   # Get the options.
 
@@ -364,10 +368,18 @@ compdef() {
         else
           case "$type" in
           pattern)
-            _patcomps[$1]="$func"
+	    if [[ $1 = (#b)(*)=(*) ]]; then
+	      _patcomps[$match[1]]="=$match[2]=$func"
+	    else
+	      _patcomps[$1]="$func"
+	    fi
             ;;
           postpattern)
-            _postpatcomps[$1]="$func"
+	    if [[ $1 = (#b)(*)=(*) ]]; then
+	      _postpatcomps[$match[1]]="=$match[2]=$func"
+	    else
+	      _postpatcomps[$1]="$func"
+	    fi
             ;;
           *)
             if [[ "$1" = *\=* ]]; then
Index: Completion/Base/Core/_dispatch
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Core/_dispatch,v
retrieving revision 1.4
diff -p -u -r1.4 _dispatch
--- Completion/Base/Core/_dispatch	3 Jun 2004 15:14:59 -0000	1.4
+++ Completion/Base/Core/_dispatch	6 Dec 2010 16:06:47 -0000
@@ -2,6 +2,7 @@
 
 local comp pat val name i ret=1 _compskip="$_compskip"
 local curcontext="$curcontext" service str noskip
+local -a match mbegin mend
 
 # If we get the option `-s', we don't reset `_compskip'.
 
@@ -24,6 +25,10 @@ if [[ "$_compskip" != (all|*patterns*) ]
     [[ -n "$str" ]] || continue
     service="${_services[$str]:-$str}"
     for i in "${(@)_patcomps[(K)$str]}"; do
+      if [[ $i = (#b)"="([^=]#)"="(*) ]]; then
+	service=$match[1]
+	i=$match[2]
+      fi
       eval "$i" && ret=0
       if [[ "$_compskip" = *patterns* ]]; then
         break

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Using the same completion function for various commands

[Peter Stephenson]

On Mon, 6 Dec 2010 16:10:20 +0000
Peter Stephenson <Peter.Stephenson@csr.com> wrote:
> On Mon, 6 Dec 2010 16:18:47 +0100
> Mikael Magnusson <mikachu@gmail.com> wrote:
> > Ah, er, right. But. Is there any way to combine -p and saying
> > foo=du ? When I tried compdef _du -p 'foo_*=du' nothing happened.

Yes, I know, it *still* doesn't work, and you were about complain.

Is the following change to _pick_variant right?  Why we would ever
prefer $words[1] to $service, when this seems to be what $service is
for? Am I missing cases where you definitely don't want the basic
service run in order to check a variant?

Index: Completion/Base/Utility/_pick_variant
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_pick_variant,v
retrieving revision 1.2
diff -p -u -r1.2 _pick_variant
--- Completion/Base/Utility/_pick_variant	28 Feb 2009 07:11:31 -0000	1.2
+++ Completion/Base/Utility/_pick_variant	6 Dec 2010 16:18:54 -0000
@@ -7,7 +7,7 @@ local -A opts
 (( $+_cmd_variant )) || typeset -gA _cmd_variant
 
 zparseopts -D -A opts c: r:
-: ${opts[-c]:=$words[1]}
+: ${opts[-c]:=${service:-$words[1]}}
 
 while [[ $1 = *=* ]]; do
   var+=( "${1%%\=*}" "${1#*=}" )

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Using the same completion function for various commands

[Bart Schaefer]

On Dec 6,  4:21pm, Peter Stephenson wrote:
}
} Is the following change to _pick_variant right?  Why we would ever
} prefer $words[1] to $service, when this seems to be what $service is
} for?

My recollection is that $words[1] is always a command, whereas $service
may just be a placeholder name.  However, I can't provide an example
where this would introduce a problem for _pick_variant in particular.

Re: Using the same completion function for various commands

[Peter Stephenson]

On Mon, 06 Dec 2010 08:44:28 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Dec 6,  4:21pm, Peter Stephenson wrote:
> }
> } Is the following change to _pick_variant right?  Why we would ever
> } prefer $words[1] to $service, when this seems to be what $service is
> } for?
> 
> My recollection is that $words[1] is always a command, whereas
> $service may just be a placeholder name.  However, I can't provide an
> example where this would introduce a problem for _pick_variant in
> particular.

Yes, for example in _perforce I use the service as p4-<subcommand>.
But, as you imply, in that case there's no question of running
_pick_variant, we've already got into the detailed syntax another way.

We can just pass -c $service to _pick_variants, it's just that that's
yet another variable factor to go wrong, so if we can avoid it that's
good.  In particular, you don't notice it's gone wrong until a case like
the one Mikael noticed --- to put it another way, the service is a
parameter that can be set by the user, and until the user tries to map a
new command to an existing completion you don't know the completion
function needed "-c $service".

Of course, if we find a case where this doesn't work, the caller can use
"-c $words[1]".  Given that I think that's the odd case out, maybe I'll
just commit it and see what happens.

(Sigh. Good job it's only Monday...)

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Using the same completion function for various commands

[Oliver Kiddle]

Mikael Magnusson wrote:
> Ah, er, right. But. Is there any way to combine -p and saying foo=du ?
> When I tried compdef _du -p 'foo_*=du' nothing happened.

zstyle ':completion:*:foo_*::variant' command du --version

Peter wrote:
> Why we would ever prefer $words[1] to $service, when this seems
> to be what $service is for?

Aside from the case Bart mentioned, there's also cases like:
  compdef gdu=du

Oliver

Re: Using the same completion function for various commands

[Peter Stephenson]

On Mon, 06 Dec 2010 20:39:21 +0100
Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> Peter wrote:
> > Why we would ever prefer $words[1] to $service, when this seems
> > to be what $service is for?
> 
> Aside from the case Bart mentioned, there's also cases like:
>   compdef gdu=du

It looks like you can't in general distinguish between two ways of using
the service:

- A command (gdu) is an instance of a basic command (du) for which
completion exists, but under a different name (as above).  The basic
command might exist but your best bet for picking the right version
is to run the new instance.

- A command has some behaviour related to, or acts as a front end for, a
basic command but possibly doesn't fully implement it and might not be
useful for finding out the version of the interface.  Then you'd need to
run the basic command.

In the first case you have the simple alternative of defining

#compdef gdu
_du "$@"

which fixes the service for you.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Using the same completion function for various commands

[Martin Richter]

Thank you very much,

> That means it's working perfectly.
yes indeed. And as my own completion function is not as complicated as this the 
compdef with the '-P' worked perfeclty well for me.

Thanks again,
Martin

Re: Using the same completion function for various commands

[Jérémie Roquet]

2010/12/6 Peter Stephenson <Peter.Stephenson@csr.com>:
> On Mon, 6 Dec 2010 16:03:51 +0100
> Mikael Magnusson <mikachu@gmail.com> wrote:
>
>> 2010/12/6 Jérémie Roquet <arkanosis@gmail.com>:
>> > Hi,
>> >
>> > 2010/12/6 Mikael Magnusson <mikachu@gmail.com>:
>> >> You can also do this in your .zshrc instead of in the completer if
>> >> you wish, just write
>> >> compdef _foo -p 'foo_*'
>> >>
>> >> At least that's what the documentation says, it doesn't seem to
>> >> work that well.
>> >
>> > It works fine for me with 4.3.10, did I miss something?
>>
>> When i tried compdef _du -p foo_\*, i only got single-letter options
>> completed.
>>
>
> That means it's working perfectly.  It's hitting this line at the top of
> _du
>
>  _pick_variant gnu=Free\ Soft unix --version /dummy/no-such-file
>
> and deciding, quite reasonably in my opinion, that foo_\* is not a GNU
> variant of du.  So it's going to the other branch, where the options are
> simpler.

I'm getting some weird behaviour with some commands, though. For example :

$ aap -<tab>
--                          -- end of options, targets and assignments follow
--changed                   -- consider specified file changed
--command         -c        -- execute a command after reading the recipe
--contents        -C        -- only build when file contents changed
<snip>

$ compdef _aap bar
$ bar -<tab>
--                          -- end of options, targets and assignments follow
--changed                   -- consider specified file changed
--command         -c        -- execute a command after reading the recipe
--contents        -C        -- only build when file contents changed
<snip>

$ compdef _aap -p baz
$ baz -<tab>
zsh: do you wish to see all 1152 possibilities (1154 lines)?<y>
option
--
--changed
--command
--contents
<snip>
<space>
<space>
<snip>
-c
-C
-k
<snip>
<space>
<space>
<snip>
-- end of options, targets and assignments follow
-- consider specified file changed
-- execute a command after reading the recipe
<snip>

I guess there is something wrong in _aap, but I don't understand why
the behaviour is different with and without the -p

Best regards,

-- 
Jérémie