* Using the same completion function for various commands @ 2010-12-06 14:12 Martin Richter 2010-12-06 14:54 ` Mikael Magnusson 0 siblings, 1 reply; 14+ messages in thread From: Martin Richter @ 2010-12-06 14:12 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Using the same completion function for various commands 2010-12-06 14:12 Using the same completion function for various commands Martin Richter @ 2010-12-06 14:54 ` Mikael Magnusson 2010-12-06 15:01 ` Jérémie Roquet 0 siblings, 1 reply; 14+ messages in thread From: Mikael Magnusson @ 2010-12-06 14:54 UTC (permalink / raw) To: mrichter; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Using the same completion function for various commands 2010-12-06 14:54 ` Mikael Magnusson @ 2010-12-06 15:01 ` Jérémie Roquet 2010-12-06 15:03 ` Mikael Magnusson 0 siblings, 1 reply; 14+ messages in thread From: Jérémie Roquet @ 2010-12-06 15:01 UTC (permalink / raw) To: Zsh Users; +Cc: mrichter, Mikael Magnusson 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Using the same completion function for various commands 2010-12-06 15:01 ` Jérémie Roquet @ 2010-12-06 15:03 ` Mikael Magnusson 2010-12-06 15:11 ` Peter Stephenson 0 siblings, 1 reply; 14+ messages in thread From: Mikael Magnusson @ 2010-12-06 15:03 UTC (permalink / raw) To: Jérémie Roquet; +Cc: Zsh Users, mrichter 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Using the same completion function for various commands 2010-12-06 15:03 ` Mikael Magnusson @ 2010-12-06 15:11 ` Peter Stephenson 2010-12-06 15:18 ` Mikael Magnusson ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Peter Stephenson @ 2010-12-06 15:11 UTC (permalink / raw) To: Zsh Users 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Using the same completion function for various commands 2010-12-06 15:11 ` Peter Stephenson @ 2010-12-06 15:18 ` Mikael Magnusson 2010-12-06 16:10 ` Peter Stephenson 2010-12-06 19:39 ` Oliver Kiddle 2010-12-06 15:23 ` Martin Richter 2010-12-06 15:31 ` Jérémie Roquet 2 siblings, 2 replies; 14+ messages in thread From: Mikael Magnusson @ 2010-12-06 15:18 UTC (permalink / raw) To: Zsh Users 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Using the same completion function for various commands 2010-12-06 15:18 ` Mikael Magnusson @ 2010-12-06 16:10 ` Peter Stephenson 2010-12-06 16:21 ` Peter Stephenson 2010-12-06 19:39 ` Oliver Kiddle 1 sibling, 1 reply; 14+ messages in thread From: Peter Stephenson @ 2010-12-06 16:10 UTC (permalink / raw) To: Zsh Users 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Using the same completion function for various commands 2010-12-06 16:10 ` Peter Stephenson @ 2010-12-06 16:21 ` Peter Stephenson 2010-12-06 16:44 ` Bart Schaefer 0 siblings, 1 reply; 14+ messages in thread From: Peter Stephenson @ 2010-12-06 16:21 UTC (permalink / raw) To: Zsh Users 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Using the same completion function for various commands 2010-12-06 16:21 ` Peter Stephenson @ 2010-12-06 16:44 ` Bart Schaefer 2010-12-06 17:08 ` Peter Stephenson 0 siblings, 1 reply; 14+ messages in thread From: Bart Schaefer @ 2010-12-06 16:44 UTC (permalink / raw) To: Zsh Users 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Using the same completion function for various commands 2010-12-06 16:44 ` Bart Schaefer @ 2010-12-06 17:08 ` Peter Stephenson 0 siblings, 0 replies; 14+ messages in thread From: Peter Stephenson @ 2010-12-06 17:08 UTC (permalink / raw) To: Zsh Users 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Using the same completion function for various commands 2010-12-06 15:18 ` Mikael Magnusson 2010-12-06 16:10 ` Peter Stephenson @ 2010-12-06 19:39 ` Oliver Kiddle 2010-12-07 11:52 ` Peter Stephenson 1 sibling, 1 reply; 14+ messages in thread From: Oliver Kiddle @ 2010-12-06 19:39 UTC (permalink / raw) To: Mikael Magnusson; +Cc: Zsh Users 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Using the same completion function for various commands 2010-12-06 19:39 ` Oliver Kiddle @ 2010-12-07 11:52 ` Peter Stephenson 0 siblings, 0 replies; 14+ messages in thread From: Peter Stephenson @ 2010-12-07 11:52 UTC (permalink / raw) To: Zsh Users 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Using the same completion function for various commands 2010-12-06 15:11 ` Peter Stephenson 2010-12-06 15:18 ` Mikael Magnusson @ 2010-12-06 15:23 ` Martin Richter 2010-12-06 15:31 ` Jérémie Roquet 2 siblings, 0 replies; 14+ messages in thread From: Martin Richter @ 2010-12-06 15:23 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Using the same completion function for various commands 2010-12-06 15:11 ` Peter Stephenson 2010-12-06 15:18 ` Mikael Magnusson 2010-12-06 15:23 ` Martin Richter @ 2010-12-06 15:31 ` Jérémie Roquet 2 siblings, 0 replies; 14+ messages in thread From: Jérémie Roquet @ 2010-12-06 15:31 UTC (permalink / raw) To: Peter Stephenson; +Cc: Zsh Users 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2010-12-07 11:53 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-12-06 14:12 Using the same completion function for various commands Martin Richter 2010-12-06 14:54 ` Mikael Magnusson 2010-12-06 15:01 ` Jérémie Roquet 2010-12-06 15:03 ` Mikael Magnusson 2010-12-06 15:11 ` Peter Stephenson 2010-12-06 15:18 ` Mikael Magnusson 2010-12-06 16:10 ` Peter Stephenson 2010-12-06 16:21 ` Peter Stephenson 2010-12-06 16:44 ` Bart Schaefer 2010-12-06 17:08 ` Peter Stephenson 2010-12-06 19:39 ` Oliver Kiddle 2010-12-07 11:52 ` Peter Stephenson 2010-12-06 15:23 ` Martin Richter 2010-12-06 15:31 ` Jérémie Roquet
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).