Re: off topic

[Sebastian Gniazdowski <psprint@xxxxxxxxxxx>]

Hello,
I've stumbled upon this 2016 post from Oliver. It is attached at the end. Let me share my 2-3 year experience about plugins:
- Plugin is: name.plugin.zsh sourced, $0:h added to $fpath.

So autoload functions will work and also completions, too. Such plugin manager will be very compact: a hopefully flexible git cloning code + sourcing.

The new 5.3.1-dev-0 functionality can be used to skip $fpath changes: autoloads via absolute paths. To do this, autoload() function to shadow the builtin should be added before sourcing, and it would catch user's autoload, and prepend $0:h. That's it. Nested, post-sourcing autoloads (i.e. catched "autoload X" from plugin.zsh, uncatched from within function X, at runtime) will work with the 5.3.1-dev-0 functionality.

It might sound heavy, but I shadow multiple things in Zplugin: zle, zstyle, bindkey, autoload, compdef and no problems occurred and no reports about this.

- Then goes the hidden truth about plugins, not easily discovered: plugins can call compdef, so compinit should be in place already (it defines compdef), but plugins extend $fpath.

Solution in Zplugin: compdefs are saved via shadowing compdef() function, and "zplugin cdreplay" command is provided for user, to be ran after he calls compinit, which is expected to be after all Zplugin invocations.

Solution in OMZ: plugins are given via array. OMZ can make all $fpath changes and invoke compinit before sourcing plugins, so compdef is ready to use for the plugins when sourcing them.

Possible solution: "zplugin load"-like call should append to some array, with some possible options, and then "plug apply" call would be expected from user, that would do $fpath changes, compinit and whole sourcing. That said, compdef shadowing is really nice looking and working thing, and it doesn't hide compinit somewhere in plugin manager.

- Small thing: plugins can be compiled at install, I do this from 1 year now with Zplugin, and no problems are reported. That said, other people are maybe able to squeeze milliseconds from this (heard that), but I saw no changes in loading time.

Now set of things that I plan for Zplugin after observing things for 1.4 year. I don't propose Zplugin because it's little verbose (but still rather fastest out there) with the reporting feature.

- I observed a trend to make plugin manager a swiss-knife. If you look at the first factoid I gave, then plugin manager is just clone+source. However, the swiss-knife trait can uplift this not-great state.

- Zplugin has "snippet" command, it kinda shows what's this is about: it creates directory that encodes url of a remote file:

github--DOT--com--SLASH--robbyrussell--SLASH--oh-my-zsh--SLASH--blob--SLASH--master--SLASH--lib--SLASH--git.zsh

then downloads the file into this directory, and sources it. This allows to use 99% of OMZ plugins without bloating code with OMZ-specific stuff, because 99% of plugins there are single file without autoloads. Following "snippet" commands will skip downloading. Note the advantage that this creates. You can easily update the snippet, hook it to remote location – a swiss-knife like thing resulting from simple concept.

- Such simple concepts allow clever zshrc. For example, how to load this non-plugin: https://github.com/trapd00r/LS_COLORS ? A Zplugin user did:

zplugin load trapd00r/LS_COLORS
LS_COLORS_DIR=$ZPLG_PLUGINS_DIR/trapd00r---LS_COLORS
if [[ ! $LS_COLORS_DIR/LS_COLORS.plugin.zsh -nt $LS_COLORS_DIR/LS_COLORS ]]; then
	dircolors -b $LS_COLORS_DIR/LS_COLORS > $LS_COLORS_DIR/LS_COLORS.plugin.zsh
	zplugin compile trapd00r/LS_COLORS
	source $LS_COLORS_DIR/LS_COLORS.plugin.zsh
fi

So he has single dircolors call in case of update, which is a serious asset, as author proposed doing "eval $( dircolors -b $HOME/LS_COLORS )", i.e. a fork, and eval usage probably slightly slower than source. So, a swiss-knife could be added for such fancy sourcing, that would be better than the "create plugin.zsh on -ot" user-side solution above.

- Such swiss-knife are also "hook-build" and "hook-load" in zplug/zplug (other plugin manager), which specify code to be ran after install/update and after loading.

- I can think of: option to trigger "git reset --hard HEAD" before update, and also doing "hook-build" that modifies or removes files. Compare this to normal zshrc management of things.

- "if" option, that would test "[[ some = condition ]]", and decide to load the plugin

I think this can be approached as tools for any not-conforming thing on github.

- One last thing – all my plugins do:

if [[ -z "$ZPLG_CUR_PLUGIN" && -z "${fpath[(r)$MY_REPO_DIR]}" ]]; then
    fpath+=( "$MY_REPO_DIR" )
fi

Basically, as it can be seen, plugin managers can be skipped because plugin can correctly manage $fpath itself. The official plugin manager could create standard $ZPLG_CUR_PLUGIN analogue, I would switch Zplugin to that standard parameter (indicating that plugin manager is active and no self-management of $fpath is needed).

Sebastian


On 10 Dec 2016 at 03:50:26, Oliver Kiddle wrote:
Rather than a source-able file, would it perhaps make sense to embrace
the concept of plugins.
It's a concept that people are familiar with from other software.
With vim for example, it is common to have a list in .vimrc, e.g:
  call plug#begin('~/.vim/plugged')
  Plug 'surround.vim'
  Plug 'tommcdo/vim-exchange'
  ...

The various existing zsh plugin managers are similar.

One well known plugin named sensible.vim is similar to what you
posted: defaults everyone can agree on.

I think it also tends to result in better maintained plugins when people
keep their own plugin in their own github area vs. an omz pull request
and then assuming that the omz people will look after it thereafter.

As a first step, we could add an Etc/plugin-guide file to outline
conventions such as how structure a plugin, use of add-zsh-hook,
how to avoid trampling on the rest of the user's setup. default_zstyle
could perhaps be included in Misc (or added as an option to zstyle).
Name of path variable which is used when searching for plugins, etc.
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.

We could include a rudimentary plugin manager. So people would do
something like:
  autoload -U pluginit; pluginit
  plug zsh-syntax-highlighting
  plug zsh-viexchange
Or they could continue using zplugin or whatever else if they want
fancy features like coloured github updates. And if we've kept
things simple, it could work to just source a single file for a
plugin.

Finally, we could include the odd plugin in the distribution for
anything which could be considered fairly core - such as the sensible
defaults plugin.

--
Sebastian Gniazdowski
psprint /at/ zdharma.org