Re: How completions work, do they require fpath?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 26,  6:18pm, Sebastian Gniazdowski wrote:
}
} my current understanding of the completions is that if a file-function
} with name starting with "_", and having "#compdef ..." in first line
} of content, is found in $fpath, then, if compinit is run, the function
} will be autoloaded and used by _main_complete. Am I missing something
} here?

No.

} Does this mean that compinit should be best run once after all needed
} fpath updates?

Ideally yes, but really #compdef is just a way to have the compdef
function invoked automatically for some files.  If the plugin is
already calling autoload + compdef directly, compinit isn't needed.

Note that nothing checks for conflicting #compdef, so if two files
both specify the same key bindings the one found later in fpath
will create the binding, but the one found earlier in fpath will
be autoloaded if the two have the same basename.  (So far it has
never come up for two files with the same name, though I believe
there are some conflicting key bindings.)

} A trick to avoid fpath for regular autoload functions has emerged on
} this list. Is similar trick possible for a completion? How to load one
} without running compinit and most of all, without updating fpath?

There's a chunk of code near the end of compinit that handles the
parsing of the #compdef lines.  That would need to be extracted into
its own function so it could be run repeatedly for new files.

Other than that, the shadow-autoload trick already used in zplugin
should work for completion autoloads, although they would not get
recorded in ~/.zcompdump (and you wouldn't want them to be, in that
circumstance).

On Jan 27,  8:59am, Sebastian Gniazdowski wrote:
} Subject: Re: How completions work, do they require fpath?
}
} On 27 January 2016 at 08:20, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > No, it doesn't contradict the manual.  The check for a directory named
} > "Base" is to distinguish "configure --enable-function-subdirs"

Actually I'm only partly right about that.  The real purpose of those
checks in compaudit are so that for example you can start in the zsh
source tree and run:

    Src/zsh -f
    fpath+=($PWD/Completion)
    autoload -Uz compinit
    _compdir=$PWD/Completion compinit -D

and have everything set up to do compsys testing, without having to
first "make install" etc.

} So using _compdir would be a hack, and also, someone can utilize
} _compdir for what's it's intended, and overwriting _compdir would
} broke their setup.

Correct.

} So it seems that fpath is needed.

Perhaps, but see other responses from Peter and above about compdef.

} I wanted to have fpath "clean", and I guess I can still have it

I've been a little puzzled all along about why you object to having
entries in fpath.

} like this: create ~/.zplugin/completions, add it to fpath, simlink
} any plugin's "_*" files there.

There's another possibility:  use zcompile.  Gather up the names of
all the autoloadable files defined by the plugins, and then run for
example

    zcompile ZPLUGINS $all_the_paths_of_autoloadable_files

This will create a (large) file ZPLUGINS.zwc containing all potential
autoloads.  Then just add that file name (not a directory name in
this special case) to fpath:

    fpath+=($PWD/ZPLUGINS.zwc)

and you're done.  Some checks that you don't clobber the file when
a new shell starts up are advised, because zsh typically mmap's it and
shares it.