zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <opk@zsh.org>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: compinit in emulation
Date: Thu, 21 Jan 2021 22:47:46 +0100	[thread overview]
Message-ID: <91910-1611265666.544073@yljT.3NHd.u6Oz> (raw)
In-Reply-To: <CAH+w=7bEM_qRUk5-eF=FPZPHzyF6o=Z6s3FgOqkF+OoFJWwJiQ@mail.gmail.com>

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


  reply	other threads:[~2021-01-21 21:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-21  1:22 Bart Schaefer
2021-01-21 21:47 ` Oliver Kiddle [this message]
2021-01-21 21:59   ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=91910-1611265666.544073@yljT.3NHd.u6Oz \
    --to=opk@zsh.org \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).