zsh-workers
 help / color / mirror / code / Atom feed
* 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).