* Re: Lazy loading completions [not found] ` <130418163739.ZM8718__6202.1464844749$1366328467$gmane$org@torch.brasslantern.com> @ 2013-04-19 0:53 ` Nicholas Riley 2013-04-20 15:26 ` Bart Schaefer 0 siblings, 1 reply; 2+ messages in thread From: Nicholas Riley @ 2013-04-19 0:53 UTC (permalink / raw) To: zsh-workers In article <130418163739.ZM8718__6202.1464844749$1366328467$gmane$org@torch.brassla ntern.com>, Bart Schaefer <schaefer@brasslantern.com> wrote: > compctl has been mostly deprecated for several years. You should look > into running compinit from your shell startup to set up more modern > completions. Yeah, I already do use the modern completions a lot elsewhere. I'm just trying to get this to work here :-) > In fact, someone should suggest to Doug Hellmann that he stop using > compctl commands in virtualenvwrapper.sh ... compctl won't work at all > for someone using compinit unless they've configured it to fall through > to old-style completions when no modern completion is found. Huh, sounds like it's worth a bug report. I don't have any mention of compctl in my compinit but maybe I got lucky. > } source /usr/local/bin/virtualenvwrapper_lazy.sh > } _virtualenvwrapper_load_compctl() { > } compctl + ${=_VIRTUALENVWRAPPER_API} > } virtualenvwrapper_load > } eval ${$(compctl | egrep '^'$_comp_command1' -K')[3]} > } } > > ?? Where is the value of $_comp_command1 coming from here? It's not set > by virtualenvwrapper_load or virtualenvwrapper.sh as far as I can tell, > so that egrep is doing nothing ...? It's being set by the completion system, I guess. I inserted a 'set' into the completion and grabbed the variable which contained the function name whose argument was being completed. In any case, if I can do without it using compdef, I'm all for it... > } compctl -K _virtualenvwrapper_load_compctl ${=_VIRTUALENVWRAPPER_API} > > With compinit loaded, I believe what you want here is > > _virtualenvwrapper_load_compctl() { > unset '_comps['${(k)^_comps[(R)_virtualenvwrapper_load_compctl]}']' > virtualenvwrapper_load > # Until Doug gets his act together > zmodload -i zsh/compctl > zstyle ':completion:*' use-compctl yes > _default > # After togetherness > # _normal > } > compdef _virtualenvwrapper_load_compctl ${=_VIRTUALENVWRAPPER_API} > > but I'm not entirely confident. Works great, thanks, though I now need to move the above to below where I call compinit; that may break a lot of users of virtualenvwrapper. -- Nicholas Riley <njriley@illinois.edu> ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Lazy loading completions 2013-04-19 0:53 ` Lazy loading completions Nicholas Riley @ 2013-04-20 15:26 ` Bart Schaefer 0 siblings, 0 replies; 2+ messages in thread From: Bart Schaefer @ 2013-04-20 15:26 UTC (permalink / raw) To: Nicholas Riley, zsh-workers On Apr 18, 7:53pm, Nicholas Riley wrote: } } In article } <130418163739.ZM8718__6202.1464844749$1366328467$gmane$org@torch.brassla } ntern.com>, } Bart Schaefer <schaefer@brasslantern.com> wrote: } > In fact, someone should suggest to Doug Hellmann that he stop using } > compctl commands in virtualenvwrapper.sh ... compctl won't work at all } > for someone using compinit unless they've configured it to fall through } > to old-style completions when no modern completion is found. } } Huh, sounds like it's worth a bug report. I don't have any mention of } compctl in my compinit but maybe I got lucky. I forgot that it automatically kicks in if you have the zsh/compctl module loaded, which has to autoload in order for the compctl command to work, so by calling compctl Doug is setting up the necessary conditions. However, someone could have zstyle ':completion:*' use-compctl no in their startup, which would break things. I guess actually that's less likely to be present than compinit is to be missing, so if he's going to have minimal dependencies he's made the best choice he could. } > } source /usr/local/bin/virtualenvwrapper_lazy.sh } > } _virtualenvwrapper_load_compctl() { } > } compctl + ${=_VIRTUALENVWRAPPER_API} } > } virtualenvwrapper_load } > } eval ${$(compctl | egrep '^'$_comp_command1' -K')[3]} } > } } } > } > ?? Where is the value of $_comp_command1 coming from here? } } It's being set by the completion system, I guess. Indeed, it's "leaking" down from _normal. If you try to make this work you probably want $_comp_commmand here, in some cases $_comp_command1 will be a full path. If you want to stick with Doug's approach and avoid reliance on compsys entirely, use local command_name local -a command_args read -c command_name command_args } Works great, thanks, though I now need to move the above to below where } I call compinit; that may break a lot of users of virtualenvwrapper. There's no evaluable function that's equivalent to "compctl -D" and no way to call one compctl from another (both of these are among reasons that compsys was invented in the first place), so you're sort of stuck. You might be able to fake it with: # Note, no leading underscore, so $1 and $2 will be set virtualenvwrapper_load_compctl() { local command_name local -a command_args read -c command_name command_args compctl + ${=_VIRTUALENVWRAPPER_API} virtualenvwrapper_load local loaded_compctl=${$(compctl | egrep '^'$command_name' -K')[3]} if [[ -n $loaded_compctl ]] then eval $loaded_compctl else reply=( $1*$2(N) ) # Pretend to do file completion fi } compctl -K virtualenvwrapper_load_compctl ${=_VIRTUALENVWRAPPER_API} ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-04-20 15:26 UTC | newest] Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <njriley-497078.17231118042013@news.gmane.org> [not found] ` <130418163739.ZM8718__6202.1464844749$1366328467$gmane$org@torch.brasslantern.com> 2013-04-19 0:53 ` Lazy loading completions Nicholas Riley 2013-04-20 15:26 ` Bart Schaefer
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).