Plugin conventions (was zsh-users Re: off topic)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 11,  4:32am, Daniel Shahaf wrote:
} Subject: Re: off topic
}
} Oliver Kiddle wrote on Sat, Dec 10, 2016 at 03:50:26 +0100:
} > The omz convention seems to be a single file with the extension
} > .plugin.zsh which is sourced but there may be more to it than that.
} > We also need to think about the order in which commands are run.
} 
} Whatever convention we come up with, can we please arrange for the
} plugin's code to be parsed without user options and/or aliases in
} effect?

Sebastian's plugin manager goes to quite some lengths to handle this,
as I recall, including keeping deltas of the option changes so that
any option changes made by the plugin are preserved.

An outline of a simplistic approach to same (I like using zstyle to
avoid having to invent safe parameter names):

    {
      zstyle plugin-manager user-options "${(kv)options[@]}"
      zstyle plugin-manager user-aliases "${(kv)aliases[@]}"
      emulate -R zsh
      noglob unalias -m *
      if source some.plugin.zsh
      then
        zstyle plugin-manager some.plugin-options "${(kv)options[@]}"
        zstyle plugin-manager some.plugin-aliases "${(kv)aliases[@]}"
      fi
    } always {
      zstyle -a plugin-manager user-options options
      zstyle -a plugin-manager user-aliases aliases
      # ... and then merge in the deltas ...
    }

Another tricky bit is that the plugin might want to know what the
user's options were, so would have to be aware of how the plugin
manager has saved them.