mattmc3 / antidote

https://getantidote.github.io - the cure to slow zsh plugin management
MIT License
872 stars 21 forks source link

Dynamic bundle loading: add `antidote save` to generate static load script #65

Closed wookayin closed 2 years ago

wookayin commented 2 years ago

(for more context, please continue from #63) -- I come across some idea (potentially a new feature) about how can we improve dynamic bundle loading mode.

Can we add some new command like antidote save? --- which can generate a static load script (e.g., ~/.zsh_plugin.zsh) after source <(antidote init) and antidote bundle ... directives (i.e. in the dynamic loading mode).

In the dynamic loading mode, running antidote bundle will do souring of the script and manipulation of $fpath, but these can be collected to generate the static load script (note that antidote bundle prints the static load script in the static mode). By doing so, one can make have a faster init performance by sourcing the compiled static script (if any), or generate one with the syntax of dynamic loading (see #63) rather than an use of zsh_plugins.txt.

FYI, this would be quite similar to the behavior of other zsh plugins, for instance, zgen, zgenom, antigen.

mattmc3 commented 2 years ago

I don't see the point of a save function. Save is just a re-implementation of Zsh redirection to a file, and I'd prefer not to add that complexity when that functionality is already available and built-in. Antidote centers around one simple command:

antidote bundle <~/.zsh_plugins.txt >~/.zsh_plugins.zsh

If you source <(antidote init), you've already chosen not to have a static file and want dynamic plugins. If you do want a static file, but don't want a separate .zsh_plugins.txt, you use a HEREDOC:

# clone antidote
[[ -e ${ZDOTDIR:-~}/.antidote ]] ||
  git clone --depth=1 https://github.com/mattmc3/antidote.git ${ZDOTDIR:-~}/.antidote

# config and source antidote
zstyle ':antidote:bundle' use-friendly-names 'yes'
autoload -Uz ${ZDOTDIR:-~}/.antidote/functions/antidote

# bundle plugins
if [[ ! ${ZDOTDIR:-~}/.zsh_plugins.zsh -nt ${ZDOTDIR:-~}/.zshrc ]]; then
  antidote bundle >${ZDOTDIR:-~}/.zsh_plugins.zsh <<EOBUNDLES
# prompts
romkatv/powerlevel10k

# utils
romkatv/zsh-bench kind:path

# framework
belak/zsh-utils path:history
belak/zsh-utils path:completion
belak/zsh-utils path:editor
belak/zsh-utils path:utility

# plugins
rupa/z
zsh-users/zsh-autosuggestions
zsh-users/zsh-history-substring-search
EOBUNDLES
fi

# source your 'saved' static file
source ${ZDOTDIR:-~}/.zsh_plugins.zsh
mattmc3 commented 2 years ago

If you find a HEREDOC too ugly or too limiting, you can also build your plugins list into a variable. Doing this would let you get fancy too, like adding other logic. For example, here's how you'd use an array and pipe its input into the antidote bundle command:

local -a my_bundles=(
  # prompts
  'romkatv/powerlevel10k'

  # utils
  'romkatv/zsh-bench kind:path'

  # framework
  'belak/zsh-utils path:history'
  'belak/zsh-utils path:completion'
  'belak/zsh-utils path:editor'
  'belak/zsh-utils path:utility'

  # plugins
  'rupa/z'
  'zsh-users/zsh-autosuggestions'
  'zsh-users/zsh-history-substring-search'
)

# use logic to assemble the array
if [[ $OSTYPE == darwin* ]]; then
  my_bundles+=('zshzoo/macos')
fi

# now, make the static file
printf "%s\n" $my_bundles | antidote bundle >~/.zsh_plugins.zsh
wookayin commented 2 years ago

I would respectfully disagree, I believe there is a benefit of save function.

HEREDOC is exactly what we already discussed in #63. But with dynamic loading syntax we can leverage a full flexibility that zsh script can offer. HEREDOC is fine to use but editor's syntax support is limited (e.g. it does not recognize comments) -- although there is a way to configure this at a quite bothersome work, so I think adding this feature would be a nice alternative that can have the benefits of both world. (other former plugins have such concepts too)

UPDATE: Your new comments provide an alternative way other than HEREDOC. That's a pretty clever option.

Overall if you don't want an unnecessarily complex command/logic, then it couldn't be helped but it's fine given the clever workaround you suggested. Thank you for your consideration.