compinit in emulation

compinit in emulation

[Bart Schaefer]

The documentation says:
  If the parameter _compdir is set, compinit uses it as a directory where
  completion functions can be found; this is only necessary if they are
  not already in the function search path.

However, this depends on the fpath/FPATH tied variable linkage, which
is disabled when not in native zsh mode.  I wrongly expected 'emulate
-R zsh' to fix this, and spent quite a while down a rabbit hole trying
to figure out what was wrong.

Obviously we've been getting by with this for the past couple of
decades, but:  Does anyone think this should be repaired?

Re: compinit in emulation

[Oliver Kiddle]

Bart Schaefer wrote:
> The documentation says:
>   If the parameter _compdir is set, compinit uses it as a directory where
>   completion functions can be found; this is only necessary if they are
>   not already in the function search path.

I'm not entirely clear what that feature is trying to achieve. So you
can wipe out $fpath but set _compdir to the location of the completon
functions and compinit will kindly fill out $fpath with all the
completion directories again. Assuming zsh can still find compinit in
$fpath in order to run it that is. This may relate to compaudit and
compinstall so Peter may have more idea.

> However, this depends on the fpath/FPATH tied variable linkage, which
> is disabled when not in native zsh mode.  I wrongly expected 'emulate
> -R zsh' to fix this, and spent quite a while down a rabbit hole trying
> to figure out what was wrong.

I get "compinit:141: parse error: condition expected: $1" when trying to
use the feature from sh emulation - is that what you're referring to?

When cutting it down to the absolute minimum, I can reproduce that odd
error by creating a file that contains just:
  [[ $1 = (*) ]]
Then (assuming it is named compinit):
  zsh -f
  fpath=( $PWD )
  autoload -UTz compinit
  compinit
  compinit:1: parse error: condition expected: $1

That line won't parse in other shells. The lexer gives different
results – compare with and without sh emulation:

  print -lr -- "${(z):-[[ \$1 = (#b)(*)=(*) ]]}"

So despite the use of emulate -L zsh in top of a function, emulate sh
causes sh lexer rules to be applied to the autoloaded function. Perhaps
the -z option to autoload could be overloaded and made to correct for that.

The original lines in compinit are as follows. There may be ways such as
wrapping in eval or emulate or rearranging to workaround the real
problem. (Assuming your issue wasn't something else entirely)

391       pattern)
392 	    if [[ $1 = (#b)(*)=(*) ]]; then
393 	      _patcomps[$match[1]]="=$match[2]=$func"

Oliver

Re: compinit in emulation

[Bart Schaefer]

On Thu, Jan 21, 2021 at 1:47 PM Oliver Kiddle <opk@zsh.org> wrote:
>
> Bart Schaefer wrote:
> > The documentation says:
> >   If the parameter _compdir is set, compinit uses it as a directory where
> >   completion functions can be found; this is only necessary if they are
> >   not already in the function search path.
>
> I'm not entirely clear what that feature is trying to achieve. So you
> can wipe out $fpath but set _compdir to the location of the completon
> functions and compinit will kindly fill out $fpath with all the
> completion directories again.

Well, no.  _compdir is used in compaudit, and it appends to fpath
rather than replaces it.  So that whole paragraph in the doc is wrong
if "compinit -C" is used.

> > However, this depends on the fpath/FPATH tied variable linkage, which
> > is disabled when not in native zsh mode.  I wrongly expected 'emulate
> > -R zsh' to fix this, and spent quite a while down a rabbit hole trying
> > to figure out what was wrong.
>
> I get "compinit:141: parse error: condition expected: $1" when trying to
> use the feature from sh emulation - is that what you're referring to?

No;  compaudit only appends to the fpath array, so FPATH is never
updated, so all the work compaudit does searching in $_compdir is
useless.

I avoided the parse error by using { emulate zsh -c 'autoload
compinit' } and things still fail because fpath is not tied to FPATH.