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