Software packages (plugins) in /usr/*/share/zsh/plugins

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

Hello,
after near 8 months of working with plugins I've developed several
insights about them:

1. Main goal of OMZ plugins is to separate FPATH update from plugin sourcing

        OMZ has plugins in array ($plugins), not as "omz load
plgname". So it can first update FPATH with all $plugins entries, then
call compinit, then source plugins. This gives plugins ability to call
compdef.


2. Plugins can update FPATH themselves ("standalone" plugins).

        The "-z $ZPLG_CUR_PLUGIN" is needed for Zplugin, a plugin
manager that aims at not updating FPATH at all:

REPO_DIR="${0%/*}"
if [[ -z "$ZPLG_CUR_PLUGIN" && "${fpath[(r)$REPO_DIR]}" != $REPO_DIR ]]; then
    fpath+=( "$REPO_DIR" )
fi


3. Main drawback of such standalone-plugins is that compinit will be
called after them, so no compdef available

        Other than that, compinit will work correctly, as plugins will
update FPATH and any added completions will be available.


4. Zsh could provide compdef - shadowing mechanism out of box

        Just a speculation, as I don't expect that "plugins can call
compdef instead of providing _function file" will gather any support,
but maybe it's a way to go after all? With fake compdef in place,
plugins would be allowed to call it as they like, and the calls would
be redirected to real compdef after compinit. It's really simple to
implement too, Antigen does that, Zplugin too.


5. What's the point

        Promptinit serves as example. It basically is:
- a file to be sourced, to provide set of functions
- FPATH ensured to point to some location:
  # Autoload all prompt_*_setup functions in fpath
  for theme in $^fpath/prompt_*_setup(N); do

A software package would have set of functions provided together with
it, available for autoload. I've written ~8 software packages and have
some experience with this, there are 3 kinds of files:

- First is setup file. It can provide precmd()-like stuff, needed
instantly in session. This file is sourced. Promptinit simulates this.

- Second is autoload function. Plainly, autoloaded to be called, but I
also believe files like "prompt_adam1_setup" belong to this category.

- Third is completion file.

I understand promptinit is a nice thing. Has clean invocation, prompts
are plain files, things are kept in order. With separate directories
in the proposed */plugins directory, things would went into more
software-engineering-like problematic state. Many commits, file
renames, minor updates, cleanups. Not sure if that is a good thing.
Maybe a mid way is possible:

- Serve as reference point for what plugin architecture is (points
1-4), by providing few of them

- Allow other plugin managers to pick-up the solution at user will,
e.g. someone would want to have Zplugin to lower FPATH entries and be
able to disable/enable completions

Other than that, what this really is about, is providing an
alternative to what promptinit does – it does what "source" command is
supposed to. This could make way to Zsh upstream easier for developers
of software, as they would be able to simply code scripts instead of
providing a promptinit-like shield around their solution. Turns out
that "standalone plugins" – sourced files with owned directories and
ability to update FPATH – might be the way to go.

Best regards,
Sebastian Gniazdowski