Coder Social home page Coder Social logo

zdharma-continuum / zinit Goto Github PK

View Code? Open in Web Editor NEW
2.5K 21.0 121.0 12.75 MB

🌻 Flexible and fast ZSH plugin manager

License: MIT License

Makefile 0.34% Shell 99.41% Dockerfile 0.25%
zsh zinit plugin-manager zsh-configuration zsh-plugin package-manager zinit-annex

zinit's Introduction

Zinit

MIT License zinit version zunit tests Join the chat at https://gitter.im/zdharma-continuum/zinit

Zinit is a flexible and fast Zshell plugin manager that will allow you to install everything from GitHub and other sites. Its characteristics are:

  1. Zinit is currently the only plugin manager that provides Turbo mode, which yields 50-80% faster Zsh startup (i.e., the shell will start up to 5 times faster!). Check out a speed comparison with other popular plugin managers here.

  2. The plugin manager gives reports from plugin loadings describing what aliases, functions, bindkeys, Zle widgets, zstyles, completions, variables, PATH and FPATH elements a plugin has set up. This allows one to quickly familiarize oneself with a new plugin and provides rich and easy-to-digest information which might be helpful on various occasions.

  3. Supported is the unloading of plugin and ability to list, (un)install and selectively disable, enable plugin's completions.

  4. The plugin manager supports loading plugins and libraries from Oh My Zsh or Prezto. However, the implementation isn't framework-specific and doesn't bloat the plugin manager with such code (more on this topic can be found on the Wiki, in the Introduction).

  5. The system does not use $FPATH, loading multiple plugins doesn't clutter $FPATH with the same number of entries (e.g. 10, 15 or more). Code is immune to KSH_ARRAYS and other options typically causing compatibility problems.

  6. Zinit supports special, dedicated packages that offload the user from providing long and complex commands. See the zinit-packages repository for a growing, complete list of Zinit packages and the Wiki page for an article about the feature.

  7. Also, specialized Zinit extensions — called annexes — have the ability to extend the plugin manager with new commands, URL-preprocessors (used by e.g.: zinit-annex-readurl annex), post-install and post-update hooks, and much more. See the zdharma-continuum organization for a growing, complete list of available Zinit extensions and refer to the Wiki article for an introduction on creating your annex.

Zinit Wiki

The information in this README is complemented by the Zinit Wiki. The README is an introductory overview of Zinit, while the Wiki gives complete information with examples. Make sure to read it to get the most out of Zinit.

Install

Automatic

The easiest way to install Zinit is to execute:

bash -c "$(curl --fail --show-error --silent --location https://raw.githubusercontent.com/zdharma-continuum/zinit/HEAD/scripts/install.sh)"

This will install Zinit in ~/.local/share/zinit/zinit.git. .zshrc will be updated with three lines of code that will be added to the bottom. The lines will be sourcing zinit.zsh and setting up completion for command zinit.

After installing and reloading the shell, compile Zinit via:

zinit self-update

Manual

In your .zshrc, add the following snippet

ZINIT_HOME="${XDG_DATA_HOME:-${HOME}/.local/share}/zinit/zinit.git"
[ ! -d $ZINIT_HOME ] && mkdir -p "$(dirname $ZINIT_HOME)"
[ ! -d $ZINIT_HOME/.git ] && git clone https://github.com/zdharma-continuum/zinit.git "$ZINIT_HOME"
source "${ZINIT_HOME}/zinit.zsh"

compinit):

If you source zinit.zsh after compinit, add the following snippet after sourcing zinit.zsh:

autoload -Uz _zinit
(( ${+_comps} )) && _comps[zinit]=_zinit

Reload Zsh to install Zinit:

exec zsh

Various paths can be customized; see section Customizing Paths.

Usage

Introduction

Click here to read the introduction to Zinit. It explains basic usage and some of the more unique features of Zinit, such as the Turbo mode. If you're new to Zinit, we recommend you read it at least once.

Plugins and snippets

Plugins can be loaded using load or light.

zinit load  <repo/plugin> # Load with reporting/investigating.
zinit light <repo/plugin> # Load without reporting/investigating.

If you want to source local or remote files (using direct URL), you can do so with snippet.

zinit snippet <URL>

Such lines should be added to .zshrc. Snippets are cached locally. Use the -f option to download a new version of a snippet or zinit update {URL}. You can also use zinit update --all to update all snippets (and plugins).

Example

# Plugin history-search-multi-word loaded with investigating.
zinit load zdharma-continuum/history-search-multi-word

# Two regular plugins loaded without investigating.
zinit light zsh-users/zsh-autosuggestions
zinit light zdharma-continuum/fast-syntax-highlighting

# Snippet
zinit snippet https://gist.githubusercontent.com/hightemp/5071909/raw/

Prompt(Theme) Example

This is powerlevel10k, pure, starship sample:

# Load powerlevel10k theme
zinit ice depth"1" # git clone depth
zinit light romkatv/powerlevel10k

# Load pure theme
zinit ice pick"async.zsh" src"pure.zsh" # with zsh-async library that's bundled with it.
zinit light sindresorhus/pure

# Load starship theme
# line 1: `starship` binary as command, from github release
# line 2: starship setup at clone(create init.zsh, completion)
# line 3: pull behavior same as clone, source init.zsh
zinit ice as"command" from"gh-r" \
          atclone"./starship init zsh > init.zsh; ./starship completions zsh > _starship" \
          atpull"%atclone" src"init.zsh"
zinit light starship/starship

Upgrade Zinit and plugins

Zinit can be updated to self-update and plugins to update.

# Self update
zinit self-update

# Plugin update
zinit update

# Plugin parallel update
zinit update --parallel

# Increase the number of jobs in a concurrent-set to 40
zinit update --parallel 40

Turbo and lucid

Turbo and lucid are the most used options.

Turbo Mode Turbo mode is the key to performance. It can be loaded asynchronously, which makes a huge difference when the amount of plugins increases.

Usually used as zinit ice wait"<SECONDS>", let's use the previous example:

zinit ice wait    # wait is the same as wait"0"
zinit load zdharma-continuum/history-search-multi-word

zinit ice wait"2" # load after 2 seconds
zinit load zdharma-continuum/history-search-multi-word

zinit ice wait    # also be used in `light` and `snippet`
zinit snippet https://gist.githubusercontent.com/hightemp/5071909/raw/
Lucid

Turbo mode is verbose, so you need an option for quiet.

You can use lucid:

zinit ice wait lucid
zinit load zdharma-continuum/history-search-multi-word

F&A: What is ice?

ice is zinit's options command. The option melts like ice and is used only once. (more: Ice Modifiers)

Migration

Migration from Oh-My-ZSH

Basic

zinit snippet <URL>        # Raw Syntax with URL
zinit snippet OMZ::<PATH>  # Shorthand OMZ/ (https://github.com/ohmyzsh/ohmyzsh/raw/master/)
zinit snippet OMZL::<PATH> # Shorthand OMZ/lib/
zinit snippet OMZT::<PATH> # Shorthand OMZ/themes/
zinit snippet OMZP::<PATH> # Shorthand OMZ/plugins/

Library

Importing the clipboard and termsupport Oh-My-Zsh Library Sample:

# Raw Syntax
zi snippet https://github.com/ohmyzsh/ohmyzsh/blob/master/lib/clipboard.zsh
zi snippet https://github.com/ohmyzsh/ohmyzsh/blob/master/lib/termsupport.zsh

# OMZ Shorthand Syntax
zi snippet OMZ::lib/clipboard.zsh
zi snippet OMZ::lib/termsupport.zsh

# OMZL Shorthand Syntax
zi snippet OMZL::clipboard.zsh
zi snippet OMZL::termsupport.zsh

Theme

To use themes created for Oh My Zsh you might want to first source the git library there.

Then you can use the themes as snippets (zinit snippet <file path or GitHub URL>). Some themes require not only Oh My Zsh's Git library, but also Git plugin (error about current_branch may appear). Load this Git-plugin as single-file snippet directly from OMZ.

Most themes require promptsubst option (setopt promptsubst in zshrc), if it isn't set, then prompt will appear as something like: ... $(build_prompt) ....

You might want to suppress completions provided by the git plugin by issuing zinit cdclear -q (-q is for quiet) – see below Ignoring Compdefs.

To summarize:

## Oh My Zsh Setting
ZSH_THEME="robbyrussell"

## Zinit Setting
# Must Load OMZ Git library
zi snippet OMZL::git.zsh

# Load Git plugin from OMZ
zi snippet OMZP::git
zi cdclear -q # <- forget completions provided up to this moment

setopt promptsubst

# Load Prompt
zi snippet OMZT::robbyrussell

External Theme Sample: NicoSantangelo/Alpharized

## Oh My Zsh Setting
ZSH_THEME="alpharized"

## Zinit Setting
# Must Load OMZ Git library
zi snippet OMZL::git.zsh

# Load Git plugin from OMZ
zi snippet OMZP::git
zi cdclear -q # <- forget completions provided up to this moment

setopt promptsubst

# Load Prompt
zi light NicoSantangelo/Alpharized

Frequently Asked Questions

Error occurs when loading OMZ's theme.

If the git library will not be loaded, the following errors will appear:

........:1: command not found: git_prompt_status
........:1: command not found: git_prompt_short_sha

Plugin

If it consists of a single file, you can just load it.

## Oh-My-Zsh Setting
plugins=(
  git
  dotenv
  rake
  rbenv
  ruby
)

## Zinit Setting
zi snippet OMZP::git
zi snippet OMZP::dotenv
zi snippet OMZP::rake
zi snippet OMZP::rbenv
zi snippet OMZP::ruby

Use zi ice svn if a plugin/snippet requires an entire subdirectory

  1. gitfast
  2. osx
zi ice svn
zi snippet OMZP::gitfast

zi ice svn
zi snippet OMZP::osx

Use zi ice as'completion' to directly add single file completion snippets

  1. docker
  2. fd
zi ice as"completion"
zi snippet OMZP::docker/_docker

zi ice as"completion"
zi snippet OMZP::fd/_fd

Find more information on Oh-My-Zsh + Zinit on the Wiki

Migration from Prezto

Basic

zi snippet <URL>        # Raw Syntax with URL
zi snippet PZT::<PATH>  # Shorthand PZT/ (https://github.com/sorin-ionescu/prezto/tree/master/)
zi snippet PZTM::<PATH> # Shorthand PZT/modules/

Modules

Importing the environment and terminal Prezto Modules Sample:

## Prezto Setting
zstyle ':prezto:load' pmodule 'environment' 'terminal'

## Zinit Setting
# Raw Syntax
zi snippet https://github.com/sorin-ionescu/prezto/blob/master/modules/environment/init.zsh
zi snippet https://github.com/sorin-ionescu/prezto/blob/master/modules/terminal/init.zsh

# PZT Shorthand Syntax
zi snippet PZT::modules/environment
zi snippet PZT::modules/terminal

# PZTM Shorthand Syntax
zi snippet PZTM::environment
zi snippet PZTM::terminal

Use zinit ice svn if multiple files require an entire subdirectory. Like docker, git:

zi ice svn
zi snippet PZTM::docker

zi ice svn
zi snippet PZTM::git

Use zinit ice as"null" if don't exist *.plugin.zsh, init.zsh, *.zsh-theme* files in module. Like archive:

zi ice svn as"null"
zi snippet PZTM::archive

Use zinit ice atclone"git clone <repo> <location>" if module have external module. Like completion:

zi ice \
  atclone"git clone --recursive https://github.com/zsh-users/zsh-completions.git external" \
  blockf \ # use blockf to prevent any unnecessary additions to fpath, as zinit manages fpath
  svn

zi snippet PZTM::completion

F&A: What is zstyle?

Read zstyle doc (more: What does zstyle do?).

Migration from Zgen

Oh My Zsh

More reference: check Migration from Oh-My-ZSH

# Load ohmyzsh base
zgen oh-my-zsh
zi snippet OMZL::<ALL OF THEM>

# Load ohmyzsh plugins
zgen oh-my-zsh <PATH>
zi snippet OMZ::<PATH>

Prezto

More reference: check Migration from Prezto

# Load Prezto
zgen prezto
zi snippet PZTM::<COMMENT's List> # environment terminal editor history directory spectrum utility completion prompt

# Load prezto plugins
zgen prezto <modulename>
zi snippet PZTM::<modulename>

# Load a repo as Prezto plugins
zgen pmodule <reponame> <branch>
zi ice ver"<branch>"
zi load <repo/plugin>

# Set prezto options
zgen prezto <modulename> <option> <value(s)>
zstyle ':prezto:<modulename>:' <option> <values(s)> # Set original prezto style

General

location: refer Selection of Files

zgen load <repo> [location] [branch]

zi ice ver"[branch]"
zi load <repo>
Migration from Zplug

Basic

zplug <repo/plugin>, tag1:<option1>, tag2:<option2>

zi ice tag1"<option1>" tag2"<option2>"
zi load <repo/plugin>

Tag comparison

  • as => as
  • use => pick, src, multisrc
  • ignore => None
  • from => from
  • at => ver
  • rename-to => mv, cp
  • dir => Selection(pick, ...) with rename
  • if => if
  • hook-build => atclone, atpull
  • hook-load => atload
  • frozen => None
  • on => None
  • defer => wait
  • lazy => autoload
  • depth => depth

More Examples

After installing Zinit you can start adding some actions (load some plugins) to ~/.zshrc, at bottom. Some examples:

# Load the pure theme, with zsh-async library that's bundled with it.
zi ice pick"async.zsh" src"pure.zsh"
zi light sindresorhus/pure

# A glance at the new for-syntax – load all of the above
# plugins with a single command. For more information see:
# https://zdharma-continuum.github.io/zinit/wiki/For-Syntax/
zinit for \
    light-mode \
  zsh-users/zsh-autosuggestions \
    light-mode \
  zdharma-continuum/fast-syntax-highlighting \
  zdharma-continuum/history-search-multi-word \
    light-mode \
    pick"async.zsh" \
    src"pure.zsh" \
  sindresorhus/pure

# Binary release in archive, from GitHub-releases page.
# After automatic unpacking it provides program "fzf".
zi ice from"gh-r" as"program"
zi light junegunn/fzf

# One other binary release, it needs renaming from `docker-compose-Linux-x86_64`.
# This is done by ice-mod `mv'{from} -> {to}'. There are multiple packages per
# single version, for OS X, Linux and Windows – so ice-mod `bpick' is used to
# select Linux package – in this case this is actually not needed, Zinit will
# grep operating system name and architecture automatically when there's no `bpick'.
zi ice from"gh-r" as"program" mv"docker* -> docker-compose" bpick"*linux*"
zi load docker/compose

# Vim repository on GitHub – a typical source code that needs compilation – Zinit
# can manage it for you if you like, run `./configure` and other `make`, etc.
# Ice-mod `pick` selects a binary program to add to $PATH. You could also install the
# package under the path $ZPFX, see: https://zdharma-continuum.github.io/zinit/wiki/Compiling-programs
zi ice \
  as"program" \
  atclone"rm -f src/auto/config.cache; ./configure" \
  atpull"%atclone" \
  make \
  pick"src/vim"
zi light vim/vim

# Scripts built at install (there's single default make target, "install",
# and it constructs scripts by `cat'ing a few files). The make'' ice could also be:
# `make"install PREFIX=$ZPFX"`, if "install" wouldn't be the only default target.
zi ice as"program" pick"$ZPFX/bin/git-*" make"PREFIX=$ZPFX"
zi light tj/git-extras

# Handle completions without loading any plugin; see "completions" command.
# This one is to be ran just once, in interactive session.
zi creinstall %HOME/my_completions
# For GNU ls (the binaries can be gls, gdircolors, e.g. on OS X when installing the
# coreutils package from Homebrew; you can also use https://github.com/ogham/exa)
zi ice atclone"dircolors -b LS_COLORS > c.zsh" atpull'%atclone' pick"c.zsh" nocompile'!'
zi light trapd00r/LS_COLORS

You can see an extended explanation of LS_COLORS in the Wiki.

# make'!...' -> run make before atclone & atpull
zi ice as"program" make'!' atclone'./direnv hook zsh > zhook.zsh' atpull'%atclone' src"zhook.zsh"
zi light direnv/direnv

You can see an extended explanation of direnv in the Wiki.

If you're interested in more examples, then check out the zinit-configs repository, where users have uploaded their ~/.zshrc and Zinit configurations. Feel free to submit your ~/.zshrc there if it contains Zinit commands.

You can also check out the Gallery of Zinit Invocations for some additional examples.

Also, two articles on the Wiki present an example setup here and here.

How to Use

Ice Modifiers

Following ice modifiers are to be passed to zinit ice ... to obtain described effects. The word ice means something that's added (like ice to a drink) – and in Zinit it means adding modifier to a next zinit command, and also something that's temporary because it melts – and this means that the modification will last only for a single next zinit command.

Some Ice-modifiers are highlighted and clicking on them will take you to the appropriate Wiki page for an extended explanation.

You may safely assume a given ice works with both plugins and snippets unless explicitly stated otherwise.

Cloning Options

Modifier Description
bpick Used to select which release from GitHub Releases to download, e.g. zini ice from"gh-r" as"program" bpick"*Darwin*"; zini load docker/compose. Does not work with snippets.
cloneopts Pass the contents of cloneopts to git clone. Defaults to --recursive. I.e.: change cloning options. Pass empty ice to disable recursive cloning. Does not work with snippets.
depth Pass --depth to git, i.e. limit how much of history to download. Does not work with snippets.
from Clone plugin from given site. Supported are from"github" (default), ..."github-rel", ..."gitlab", ..."bitbucket", ..."notabug" (short names: gh, gh-r, gl, bb, nb). Can also be a full domain name (e.g. for GitHub enterprise). Does not work with snippets.
proto Change protocol to git,ftp,ftps,ssh, rsync, etc. Default is https. Does not work with snippets.
pullopts Pass the contents of pullopts to git pull used when updating plugins. Does not work with snippets.
svn Use Subversion for downloading snippet. GitHub supports SVN protocol, this allows to clone subdirectories as snippets, e.g. zinit ice svn; zinit snippet OMZP::git. Other ice pick can be used to select file to source (default are: *.plugin.zsh, init.zsh, *.zsh-theme). Does not work with plugins.
ver Used with from"gh-r" (i.e. downloading a binary release, e.g. for use with as"program") – selects which version to download. Default is latest, can also be explicitly ver"latest". Works also with regular plugins and packages (pack ice) checkouts e.g. ver"abranch", i.e. a specific version. Does not work with snippets.

Selection of Files (To Source, …)

Modifier Description
multisrc Allows to specify multiple files for sourcing, enumerated with spaces as the separators (e.g. multisrc'misc.zsh grep.zsh') and also using brace-expansion syntax (e.g. multisrc'{misc,grep}.zsh'). Supports patterns.
pick Select the file to source, or the file to set as command (when using snippet --command or the ice as"program"); it is a pattern, alphabetically first matched file is being chosen; e.g. zinit ice pick"*.plugin.zsh"; zinit load ….
src Specify additional file to source after sourcing main file or after setting up command (via as"program"). It is not a pattern but a plain file name.

Conditional Loading

Modifier Description
cloneonly Don't load the plugin / snippet, only download it
has Load plugin or snippet only when given command is available (in $PATH), e.g. zinit ice has'git' ...
if Load plugin or snippet only when given condition is fulfilled, for example: zinit ice if'[[ -n "$commands[otool]" ]]'; zinit load ....
load A condition to check which should cause plugin to load. It will load once, the condition can be still true, but will not trigger second load (unless plugin is unloaded earlier, see unload below). E.g.: load'[[ $PWD = */github* ]]'.
subscribe / on-update-of Postpone loading of a plugin or snippet until the given file(s) get updated, e.g. subscribe'{~/files-*,/tmp/files-*}'
trigger-load Creates a function that loads the associated plugin/snippet, with an option (to use it, precede the ice content with !) to automatically forward the call afterwards, to a command of the same name as the function. Can obtain multiple functions to create – sparate with ;.
unload A condition to check causing plugin to unload. It will unload once, then only if loaded again. E.g.: unload'[[ $PWD != */github* ]]'.
wait Postpone loading a plugin or snippet. For wait'1', loading is done 1 second after prompt. For wait'[[ ... ]]', wait'(( ... ))', loading is done when given condition is meet. For wait'!...', prompt is reset after load. Zsh can start 80% (i.e.: 5x) faster thanks to postponed loading. Fact: when wait is used without value, it works as wait'0'.

Plugin Output

Modifier Description
lucid Skip Loaded ... message under prompt for wait, etc. loaded plugins (a subset of silent).
notify Output given message under-prompt after successfully loading a plugin/snippet. In case of problems with the loading, output a warning message and the return code. If starts with ! it will then always output the given message. Hint: if the message is empty, then it will just notify about problems.
silent Mute plugin's or snippet's stderr & stdout. Also skip Loaded ... message under prompt for wait, etc. loaded plugins, and completion-installation messages.

Completions

Modifier Description
blockf Disallow plugin to modify fpath. Useful when a plugin wants to provide completions in traditional way. Zinit can manage completions and plugin can be blocked from exposing them.
completions Do detect, install and manage completions for this plugin. Overwrites as'null' or nocompletions.
nocompletions Don't detect, install and manage completions for this plugin. Completions can be installed later with zinit creinstall {plugin-spec}.

Command Execution After Cloning, Updating or Loading

Modifier Description
atclone Run command after cloning, within plugin's directory, e.g. zinit ice atclone"echo Cloned". Ran also after downloading snippet.
atinit Run command after directory setup (cloning, checking it, etc.) of plugin/snippet but before loading.
atload Run command after loading, within plugin's directory. Can be also used with snippets. Passed code can be preceded with !, it will then be investigated (if using load, not light).
atpull Run command after updating (only if new commits are waiting for download), within plugin's directory. If starts with "!" then command will be ran before mv & cp ices and before git pull or svn update. Otherwise it is ran after them. Can be atpull'%atclone', to repeat atclone Ice-mod.
configure Runs ./configure script and by default changes the installation directory by passing --prefix=$ZPFX to the script. Runs before make'' and after make'!', you can pass '!' too to this ice (i.e.: configure'!') to make it execute earlier – before make'!' and after make'!!'. If # given in the ice value then also executes script ./autogen.sh first before running ./configure. The script is run anyway if there is no configure script. Also, when there exist another build-system related files, then it is run if no configure script is found. Currently supported systems are: CMake, scons and meson, checked-for/run in this order
countdown Causes an interruptable (by Ctrl-C) countdown 5…4…3…2…1…0 to be displayed before executing atclone'',atpull'' and make ices
cp Copy file after cloning or after update (then, only if new commits were downloaded). Example: cp "docker-c* -> dcompose". Ran after mv.
make Run make command after cloning/updating and executing mv, cp, atpull, atclone Ice mods. Can obtain argument, e.g. make"install PREFIX=/opt". If the value starts with ! then make is ran before atclone/atpull, e.g. make'!'.
mv Move file after cloning or after update (then, only if new commits were downloaded). Example: mv "fzf-* -> fzf". It uses -> as separator for old and new file names. Works also with snippets.
nocd Don't switch the current directory into the plugin's directory when evaluating the above ice-mods atinit'',atload'', etc.
reset Invokes git reset --hard HEAD for plugins or svn revert for SVN snippets before pulling any new changes. This way git or svn will not report conflicts if some changes were done in e.g.: atclone'' ice. For file snippets and gh-r plugins it invokes rm -rf *.
run-atpull Always run the atpull hook (when updating), not only when there are new commits to be downloaded.

Sticky-Emulation Of Other Shells

Modifier Description
sh/!sh Source the plugin's (or snippet's) script with sh emulation so that also all functions declared within the file will get a sticky emulation assigned – when invoked they'll execute also with the sh emulation set-up. The !sh version switches additional options that are rather not important from the portability perspective.
csh/!csh The same as sh, but emulating csh shell.
ksh/!ksh The same as sh, but emulating ksh shell.
bash/!bash The same as sh, but with the SH_GLOB option disabled, so that Bash regular expressions work.

Others

Modifier Description
as Can be as"program" (also the alias: as"command"), and will cause to add script/program to $PATH instead of sourcing (see pick). Can also be as"completion" – use with plugins or snippets in whose only underscore-starting _* files you are interested in. The third possible value is as"null" – a shorthand for pick"/dev/null" nocompletions – i.e.: it disables the default script-file sourcing and also the installation of completions.
link Use a symlink to cache a local snippet instead of copying into the snippets directory. Uses relative links if realpath >= 8.23 is found. Does not apply to URL-based snippets. Does not work with plugins.
id-as Nickname a plugin or snippet, to e.g. create a short handler for long-url snippet.
subst Substitute the given string into another string when sourcing the plugin script, e.g.: zinit subst'autoload → autoload -Uz' ….
aliases Load the plugin with the aliases mechanism enabled. Use with plugins that define and use aliases in their scripts.
autoload Autoload the given functions (from their files). Equvalent to calling atinit'autoload the-function'. Supports renaming of the function – pass '… → new-name' or '… -> new-name', e.g.: zinit autoload'fun → my-fun; fun2 → my-fun2'.
bindmap To hold ;-separated strings like Key(s)A -> Key(s)B, e.g. ^R -> ^T; ^A -> ^B. In general, bindmap''changes bindings (done with the bindkey builtin) the plugin does. The example would cause the plugin to map Ctrl-T instead of Ctrl-R, and Ctrl-B instead of Ctrl-A. Does not work with snippets.
compile Pattern (+ possible {...} expansion, like {a/*,b*}) to select additional files to compile, e.g. `compile"(pure\
extract Performs archive extraction supporting multiple formats like zip, tar.gz, etc. and also notably OS X dmg images. If it has no value, then it works in the auto mode – it automatically extracts all files of known archive extensions IF they aren't located deeper than in a sub-directory (this is to prevent extraction of some helper archive files, typically located somewhere deeper in the tree). If no such files will be found, then it extracts all found files of known type – the type is being read by the file Unix command. If not empty, then takes names of the files to extract. Refer to the Wiki page for further information.
service Make following plugin or snippet a service, which will be ran in background, and only in single Zshell instance. See the zservice-* repositories.
light-mode Load the plugin without the investigating, i.e.: as if it would be loaded with the light command. Useful for the for-syntax, where there is no load nor light subcommand
nocompile Don't try to compile pick-pointed files. If passed the exclamation mark (i.e. nocompile'!'), then do compile, but after make'' and atclone'' (useful if Makefile installs some scripts, to point pick'' at the location of their installation).
trackbinds Shadow but only bindkey calls even with zinit light ..., i.e. even with investigating disabled (fast loading), to allow bindmap to remap the key-binds. The same effect has zinit light -b ..., i.e. additional -b option to the light-subcommand. Does not work with snippets.
wrap-track Takes a ;-separated list of function names that are to be investigated (meaning gathering report and unload data) once during execution. It works by wrapping the functions with a investigating-enabling and disabling snippet of code. In summary, wrap-track allows to extend the investigating beyond the moment of loading of a plugin. Example use is to wrap-track a precmd function of a prompt (like _p9k_precmd() of powerlevel10k) or other plugin that postpones its initialization till the first prompt (like e.g.: zsh-autosuggestions). Does not work with snippets.
reset-prompt Reset the prompt after loading the plugin/snippet (by issuing zle .reset-prompt). Note: normally it's sufficient to precede the value of wait'' ice with !.

Order of Execution

Order of execution of related Ice-mods: atinit -> atpull! -> make'!!' -> mv -> cp -> make! -> atclone/atpull -> make -> (plugin script loading) -> src -> multisrc -> atload.

Zinit Commands

Following commands are passed to zinit ... to obtain described effects.

Help

Command Description
help Usage information.
man Manual.
version Display Zinit version

Loading and Unloading

Command Description
load {plg-spec} Load plugin, can also receive absolute local path.
snippet [-f] {url} Source local or remote file (by direct URL). -f – don't use cache (force redownload). The URL can use the following shorthands: PZT:: (Prezto), PZTM:: (Prezto module), OMZ:: (Oh My Zsh), OMZP:: (OMZ plugin), OMZL:: (OMZ library), OMZT:: (OMZ theme), e.g.: PZTM::environment, OMZP::git, etc.
light [-b] {plg-spec} Light plugin load, without reporting/investigating. -b – investigate bindkey-calls only. There's also light-mode ice which can be used to induce the no-investigating (i.e.: light) loading, regardless of the command used.
unload [-q] {plg-spec} Unload plugin loaded with zinit load .... -q – quiet.

Completions

Command Description
cclear Clear stray and improper completions.
cdclear [-q] Clear compdef replay list. -q – quiet.
cdisable {cname} Disable completion cname.
cdlist Show compdef replay list.
cdreplay [-q] Replay compdefs (to be done after compinit). -q – quiet.
cenable {cname} Enable completion cname.
completions \[*columns*\] List completions in use, with columns completions per line. zpl clist 5 will for example print 5 completions per line. Default is 3.
compinit Refresh installed completions.
creinstall [-q] [-Q] {plg-spec} Install completions for plugin, can also receive absolute local path. -q – quiet. -Q - quiet all.
csearch Search for available completions from any plugin.
cuninstall {plg-spec} Uninstall completions for plugin.

Tracking of the Active Session

Command Description
dclear Clear report of what was going on in session.
dstop Stop investigating what's going on in session.
dreport Report what was going on in session.
dunload Revert changes recorded between dstart and dstop.
dtrace, dstart Start investigating what's going on in session.

Reports and Statistics

Command Description
bindkeys Lists bindkeys set up by each plugin.
list-plugins [keyword] Show what plugins are loaded (filter with 'keyword').
list-snippets List snippets in formatted and colorized manner. Requires tree program.
recently [time-spec] Show plugins that changed recently, argument is e.g. 1 month 2 days.
report {plg-spec} Show plugin report. --all – do it for all plugins.
status {plg-spec} Git status for plugin or svn status for snippet. --all – do it for all plugins and snippets.
zstatus Display brief statistics for your Zinit installation.
times [-a] [-m] [-s] Print load times for each plugin. -s – Times are printed in seconds. -m – Show plugin loading moments. -a - Times and loading moments are printed.

Compiling

compile

List plugins that are compiled.

zinit [options] compile PLUGIN
Option Description
-a, --all Compile all plugins
-h, --help Print usage
-q, --quiet Suppress the build output

compiled

List plugins that are compiled.

zinit compiled

uncompile

List plugins that are compiled.

zinit [options] uncompile PLUGIN
Option Description
-a, --all Remove any compiled files for all plugins
-h, --help Print usage
-q, --quiet Suppress the output

Other

Command Description
module Manage binary Zsh module shipped with Zinit, see zinit module help.
self-update Updates and compiles Zinit.
cd {plg-spec} Cd into plugin's directory. Also support snippets if fed with URL.
edit {plg-spec} Edit plugin's file with $EDITOR.
changes {plg-spec} View plugin's git log.
create {plg-spec} Create plugin (also together with GitHub repository).
glance {plg-spec} Look at plugin's source (pygmentize, {,source-}highlight).
stress {plg-spec} Test plugin for compatibility with set of options.
recall {plg-spec}|URL Fetch saved ice modifiers and construct zinit ice ... command.
srv {service-id} [cmd] Control a service, command can be: stop,start,restart,next,quit; next moves the service to another Zshell.
ice <ice specification> Add ice to next command, argument is e.g. from"gitlab".
env-whitelist [-v] [-h] {env..} Allows to specify names (also patterns) of variables left unchanged during an unload. -v – verbose.
run [-l] [plugin] {command} Runs the given command in the given plugin's directory. If the option -l will be given then the plugin should be skipped – the option will cause the previous plugin to be reused.
delete {plg-spec}|URL|--clean|--all Remove plugin or snippet from disk (good to forget wrongly passed ice-mods).
--all – purge.
--clean – delete plugins and snippets that are not loaded.
update [-q] [-r] {plg-spec}|URL|--all Git update plugin or snippet.
--all – update all plugins and snippets.
-q – quiet.
-r | --reset – run git reset --hard / svn revert before pulling changes.
add-fpath|fpath [-f|--front] {plg-spec} [subdirectory] Adds given plugin (not yet snippet) directory to $fpath. If the second argument is given, it is appended to the directory path. If the option -f/--front is given, the directory path is prepended instead of appended to $fpath. The {plg-spec} can be absolute path, i.e.: it's possible to also add regular directories.

Updating Zinit and Plugins

To update Zinit issue zinit self-update in the command line.

To update all plugins and snippets, issue zinit update. If you wish to update only a single plugin/snippet instead issue zinit update NAME_OF_PLUGIN. A list of commits will be shown:

Some plugins require performing an action each time they're updated. One way you can do this is by using the atpull ice modifier. For example, writing zinit ice atpull'./configure' before loading a plugin will execute ./configure after a successful update. Refer to Ice Modifiers for more information.

The ice modifiers for any plugin or snippet are stored in their directory in a ._zinit subdirectory, hence the plugin doesn't have to be loaded to be correctly updated. There's one other file created there, .zinit_lstupd – it holds the log of the new commits pulled-in in the last update.

Completions

Calling compinit Without Turbo Mode

With no Turbo mode in use, compinit can be called normally, i.e.: as autoload compinit; compinit. This should be done after loading of all plugins and before possibly calling zinit cdreplay.

The cdreplay subcommand is provided to re-play all catched compdef calls. The compdef calls are used to define a completion for a command. For example, compdef _git git defines that the git command should be completed by a _git function.

The compdef function is provided by compinit call. As it should be called later, after loading all of the plugins, Zinit provides its own compdef function that catches (i.e.: records in an array) the arguments of the call, so that the loaded plugins can freely call compdef. Then, the cdreplay (compdef-replay) can be used, after compinit will be called (and the original compdef function will become available), to execute all detected compdef calls. To summarize:

ZINIT_HOME="${XDG_DATA_HOME:-${HOME}/.local/share}/zinit/zinit.git"
source "${ZINIT_HOME}/zinit.zsh"

zinit load "some/plugin"
...
compdef _gnu_generic fd  # this will be intercepted by Zinit, because as the compinit
                         # isn't yet loaded, thus there's no such function `compdef'; yet
                         # Zinit provides its own `compdef' function which saves the
                         # completion-definition for later possible re-run with `zinit
                         # cdreplay' or `zicdreplay' (the second one can be used in hooks
                         # like atload'', atinit'', etc.)
...
zinit load "other/plugin"

autoload -Uz compinit
compinit

# -q is for quiet; actually run all the `compdef's saved before `compinit` call
# (`compinit' declares the `compdef' function, so it cannot be used until
# `compinit' is ran; Zinit solves this via intercepting the `compdef'-calls and
# storing them for later use with `zinit cdreplay')

zinit cdreplay -q

This allows to call compinit once. Performance gains are huge, example shell startup time with double compinit: 0.980 sec, with cdreplay and single compinit: 0.156 sec.

Calling compinit With Turbo Mode

If you load completions using wait'' Turbo mode then you can add atinit'zicompinit' to syntax-highlighting plugin (which should be the last one loaded, as their (2 projects, z-sy-h & f-sy-h) documentation state), or atload'zicompinit' to last completion-related plugin. zicompinit is a function that just runs autoload compinit; compinit, created for convenience. There's also zicdreplay which will replay any caught compdefs so you can also do: atinit'zicompinit; zicdreplay', etc. Basically, the whole topic is the same as normal compinit call, but it is done in atinit or atload hook of the last related plugin with use of the helper functions (zicompinit,zicdreplay & zicdclear – see below for explanation of the last one). To summarize:

ZINIT_HOME="${XDG_DATA_HOME:-${HOME}/.local/share/zinit}"
source "${ZINIT_HOME}/zinit.zsh"

# Load using the for-syntax
zinit lucid wait for \
  "some/plugin"

zinit lucid wait for \
  "other/plugin"

zi for \
    atload"zicompinit; zicdreplay" \
    blockf \
    lucid \
    wait \
  zsh-users/zsh-completions

Ignoring Compdefs

If you want to ignore compdefs provided by some plugins or snippets, place their load commands before commands loading other plugins or snippets, and issue zinit cdclear (or zicdclear, designed to be used in hooks like atload''):

ZINIT_HOME="${XDG_DATA_HOME:-${HOME}/.local/share}/zinit/zinit.git"
source "${ZINIT_HOME}/zinit.zsh"

zi snippet OMZP::git
zi cdclear -q # <- forget completions provided by Git plugin

zi load "some/plugin"
...
zi load "other/plugin"

autoload -Uz compinit
compinit
zi cdreplay -q # <- execute compdefs provided by rest of plugins
zi cdlist # look at gathered compdefs

The cdreplay is important if you use plugins like OMZP::kubectl or asdf-vm/asdf, because these plugins call compdef.

Disabling System-Wide compinit Call (Ubuntu)

On Ubuntu users might get surprised that e.g. their completions work while they didn't call compinit in their .zshrc. That's because the function is being called in /etc/zshrc. To disable this call – what is needed to avoid the slowdown and if user loads any completion-equipped plugins, i.e. almost on 100% – add the following lines to ~/.zshenv:

# Skip the not really helping Ubuntu global compinit
skip_global_compinit=1

Zinit Module

The module is now hosted in its own repository

Hints and Tips

Using ZPFX variable

Zinit uses a special, short named variable $ZPFX to denote a standard "prefix" for installing compiled software. Such, commonly used, prefixes are usually, e.g.: /usr/,/usr/local or $HOME/.local. Basically, when one would want to explain what a prefix-dir is in one sentence, it would be something like: a root directory, under which …/bin,…/share, …/lib sub-dirs are populated with installed binaries, data-files, libraries, etc.

How to use the variable? It is automatically exploited when using configure'' and make'' ices, and user doesn't have to take any actions. This means that the configure command that'll be run will be:

./configure --prefix=$ZPFX

The default location used for $ZPFX is: ~/.local/share/zinit/polaris. You can, for example, set it to $HOME/.local to have the software installed with configure'' and make'' ices installed to that directory.

Typical use cases when working with $ZPFX are, e.g.:

$ ls $ZPFX
$ cd $ZPFX
$ cd $ZPFX/bin  # note: $ZPFX/bin is automatically prepended to $PATH
$ cd $ZPFX/share

Before the configure'' ice appeared one would use $ZPFX as follows:

zinit atclone'./configure --prefix=$ZPFX` atpull'%atclone' make \
        for universal-ctags/ctags

but now it's sufficient to do:

# Will work for any build system
# (supported are: configure, cmake, scons and meson)
zinit configure make for universal-ctags/ctags

To set ZPFX, one should do (in .zshrc before loading zinit):

$ export ZPFX=$HOME/my-software # or: ZPFX=$HOME/.local, etc.

We encourage people to install compiled software with use of $ZPFX and configure'' and make'' ices, to have a nice, clean user-home dir based setup.

Customizing Paths

Following variables can be set to custom values, before sourcing Zinit. The previous global variables like $ZPLG_HOME have been removed to not pollute the namespace – there's single $ZINIT hash instead of 8 string variables. Please update your dotfiles.

declare -A ZINIT  # initial Zinit's hash definition, if configuring before loading Zinit, and then:
Hash Field Description
ZINIT[BIN_DIR] Where Zinit code resides, e.g.: "~/.local/share/zinit/zinit.git"
ZINIT[HOME_DIR] Where Zinit should create all working directories, e.g.: "~/.local/share/zinit"
ZINIT[MAN_DIR] Directory where plugins can store their manpages (atclone"cp -vf myplugin.1 $ZINIT[MAN_DIR]/man1"). If overridden, this directory will not necessarily be used by man (See #8). Default: $ZPFX/man
ZINIT[PLUGINS_DIR] Override single working directory – for plugins, e.g. "/opt/zsh/zinit/plugins"
ZINIT[COMPLETIONS_DIR] As above, but for completion files, e.g. "/opt/zsh/zinit/root_completions"
ZINIT[SNIPPETS_DIR] As above, but for snippets
ZINIT[LIST_COMMAND] Command to use for displaying a directory tree (e.g., ls --tree, tree, etc.)
ZINIT[ZCOMPDUMP_PATH] Path to .zcompdump file, with the file included (i.e. its name can be different)
ZINIT[COMPINIT_OPTS] Options for compinit call (i.e. done by zicompinit), use to pass -C to speed up loading
ZINIT[MUTE_WARNINGS] If set to 1, then mutes some of the Zinit warnings, specifically the plugin already registered warning
ZINIT[OPTIMIZE_OUT_DISK_ACCESSES] If set to 1, then Zinit will skip checking if a Turbo-loaded object exists on the disk. By default Zinit skips Turbo for non-existing objects (plugins or snippets) to install them before the first prompt – without any delays, during the normal processing of zshrc. This option can give a performance gain of about 10 ms out of 150 ms (i.e.: Zsh will start up in 140 ms instead of 150 ms).
ZINIT[NO_ALIASES] If set to 1, then Zinit will not set aliases such as zi or zini

There is also $ZPFX, set by default to ~/.local/share/zinit/polaris – a directory where software with Makefile, etc. can be pointed to, by e.g. atclone'./configure --prefix=$ZPFX'.

Non-GitHub (Local) Plugins

Use create subcommand with user name _local (the default) to create plugin's skeleton in $ZINIT[PLUGINS_DIR]. It will be not connected with GitHub repository (because of user name being _local). To enter the plugin's directory use cd command with just plugin's name (without _local, it's optional).

If user name will not be _local, then Zinit will create repository also on GitHub and setup correct repository origin.

Extending Git

There are several projects that provide git extensions. Installing them with Zinit has many benefits:

  • all files are under $HOME – no administrator rights needed,
  • declarative setup (like Chef or Puppet) – copying .zshrc to different account brings also git-related setup,
  • easy update by e.g. zinit update --all.

Below is a configuration that adds multiple git extensions, loaded in Turbo mode, 1 second after prompt, with use of the Bin-Gem-Node annex:

zi as'null' lucid sbin wait'1' for \
  Fakerr/git-recall \
  davidosomething/git-my \
  iwata/git-now \
  paulirish/git-open \
  paulirish/git-recent \
    atload'export _MENU_THEME=legacy' \
  arzzen/git-quick-stats \
    make'install' \
  tj/git-extras \
    make'GITURL_NO_CGITURL=1' \
    sbin'git-url;git-guclone' \
  zdharma-continuum/git-url

Target directory for installed files is $ZPFX (~/.local/share/zinit/polaris by default).

Changelog

Link to the CHANGELOG.

Support

Zinit is a personal, free-time project with no funding and a huge feature request backlog. If you love it, consider supporting its development via GitHub Sponsors [pending]. Any help counts!

Getting Help and Community

Do you need help or wish to get in touch with other Zinit users?

zinit's People

Contributors

agkozak avatar akatrevorjay avatar alichtman avatar aloxaf avatar black7375 avatar davidosomething avatar dependabot[bot] avatar docwhat avatar findnextstep avatar foriequal0 avatar freed-wu avatar gitter-badger avatar gnumoksha avatar hallaji avatar jankatins avatar miles170 avatar nbrown avatar nicholas85 avatar pschmitt avatar psprint avatar robobenklein avatar romkatv avatar ryooooooga avatar sashaweiss avatar shayneholmes avatar tony avatar twang817 avatar vladdoster avatar xpmo avatar yutkat avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

zinit's Issues

Document purpose of organization and/or repo

I would suggest that we document the purpose of the organization and/or just this repo.

The I WANT TO HELP readme is a good start though it is mainly a broad "this happened and I had to take emergency action".

The information I'd be interested is:

  • Can we expect bug fixes once things settle down?
  • Can we expect security fixes?
  • How about new features?
  • Or even evolve into new things?

For example, the whole flag'value' thing (instead of --flag=value, while technically cool, is very non-standard and hinders adoption. Even if the feature is kept, the docs should probably shift to the (also supported) long-opt format (--flag=value).

Question: How to migrate from zdharma/zinit?

I used zinit before it was deleted, and I wanted to migrate to the new repository.
In ~/.zinit/bin, I ran:

git remote set-url origin https://github.com/zdharma-continuum/zinit.git

It seems to have worked; zinit self-update pulls from the new URL.
Screen Shot 2021-11-08 at 5 57 40 PM

Is this the recommended way of migrating? Perhaps some documentation could be added to the README to help other users.

Automatic install failed on MacOS

Describe the bug
When I run Automatic Install, the "mktemp" command exits with illegal options.

Zinit config
No

Expected behavior
Automatic install success.

Screenshots (optional)
No

Versions:

  • $ZSH_VERSION == zsh 5.8 (x86_64-apple-darwin20.0)
  • Operating system name and version (uname -a): Darwin mintrabi.local 20.6.0 Darwin Kernel Version 20.6.0: Tue Oct 12 18:33:42 PDT 2021; root:xnu-7195.141.8~1/RELEASE_X86_64 x86_64

Additional context
#43

🌍 Translate the polish comments

There are few comments in zinit's codebase that are in polish.

We need to:

  • Find them! (is there a regex for polish words? :D)
  • Translate them!

Examples:

zinit/zinit.zsh

Lines 255 to 257 in 5e3e668

# "Elementy fpath" – tj. te elementy, które leżą wewnątrz katalogu wtyczki.
# Nazwa wynika z tego, że są to wybrane elementy fpath → a więc po prostu
# "elementy".

Clean up the README

Here is my plan:

  • Move the out of date NEWS section to NEWS.md (or: CHANGELOG.md)
  • Rename the modules install section title to Module installation (people may click on that in the TOC expecting to find the zinit install instructions)

zdharma/zinit repository does not exist

Describe the bug
zdharma/zinit repository does not exist when try to install zinit from doc/install.sh

To Reproduce

sh -c "$(curl -fsSL https://raw.githubusercontent.com/zdharma-continuum/zinit/master/doc/install.sh)"

Expected behavior
install zinit

Versions:
zsh 5.8 (x86_64-apple-darwin21.0)

💡 Proposal: Remove the remaining zplugin stuff

Eyeing a future (and first) release of the post-psprint era I'd like to properly remove all remaining compatibility for zplugin.

The 4.0 milestone is a major one so I think it is fair to finally remove compatibility with zplugin.
People using this here repo are by default already using zinit. We never hosted zplugin.

Let's get rid of:

  • zplugin-autoload.zsh
  • zplugin-install.zsh
  • zplugin-side.zsh
  • zplugin.zsh

Any objections?

`zinit pack'5.8' for zsh` is broken

Describe the bug

The command zinit pack'5.8' for zsh is broken, but I'm not quite sure why.

To Reproduce

zinit pack'5.8' for zsh

Expected behavior

Following command would build zsh 5.8:

zinit pack'5.8' for zsh

🐞 bug: `__git_zsh_bash_func:9: command not found: __git_aliased_command` when calling `zicompinit`

Issue description

Any time I call zicompinit, git's completion gets polluted by errors.

% git com<TAB>
_git:.:42: no such file or directory:

% git commit<TAB>
% git commit __git_zsh_bash_func:9: command not found: __git_aliased_command
  git commit

git version 2.31.1

zinit config

# Zinit
# sh -c "$(curl -fsSL https://git.io/zinit-install)"
### Added by Zinit's installer
if [[ ! -f $HOME/.local/share/zinit/zinit.git/zinit.zsh ]]; then
    print -P "%F{33} %F{220}Installing %F{33}ZDHARMA-CONTINUUM%F{220} Initiative Plugin Manager (%F{33}zdharma-continuum/zinit%F{220})…%f"
    command mkdir -p "$HOME/.local/share/zinit" && command chmod g-rwX "$HOME/.local/share/zinit"
    command git clone https://github.com/zdharma-continuum/zinit "$HOME/.local/share/zinit/zinit.git" && \
        print -P "%F{33} %F{34}Installation successful.%f%b" || \
        print -P "%F{160} The clone has failed.%f%b"
fi

source "$HOME/.local/share/zinit/zinit.git/zinit.zsh"
autoload -Uz _zinit
(( ${+_comps} )) && _comps[zinit]=_zinit

# Load a few important annexes, without Turbo
# (this is currently required for annexes)
zinit light-mode for \
    zdharma-continuum/zinit-annex-as-monitor \
    zdharma-continuum/zinit-annex-bin-gem-node \
    zdharma-continuum/zinit-annex-patch-dl \
    zdharma-continuum/zinit-annex-rust

# Plugins
# https://github.com/zdharma-continuum/fast-syntax-highlighting#zinit
zinit wait lucid light-mode for \
    atinit"ZINIT[COMPINIT_OPTS]=-C; zicompinit; zicdreplay" \
        zdharma-continuum/fast-syntax-highlighting

zinit version or commit ID

19347ba

zsh version

5.8

wrong packages url in .zinit-get-package

Describe the bug

I am not able to install packages using the pack"" ice — I assume this is because the .zinit-get-package function has the wrong URL prefix zinit-package-... hardcoded:

URL=https://raw.githubusercontent.com/zdharma-continuum/zinit-package-$2/main/package.json

while the packages live under zsh-package-..., e.g. https://github.com/zdharma-continuum/zsh-package-fzf

To Reproduce

I have the following in my .zshrc

zinit wait"1" lucid if'[[ -z "$commands[fzf]" ]]' pack"bgn-binary+keys" for fzf

I get the following output when I open a new shell:

.zinit-get-package:25: datei oder Verzeichnis nicht gefunden: /tmp/tmp.06wsNmEHUB                                       
Error: the package `fzf` couldn't be found.

Expected behavior

Correcting the URL in zinit-install.zsh, and deleting the compiled .zwc fix this issue, and the packages install as expected.

Versions:

  • $ZSH_VERSION == 5.7.1
  • Operating system name and version (uname -a): Linux pi4 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux

💡 Proposal: Drop `doc/NEWS.md`

It's out of date and the CHANGELOG seems to be a better place for updating people about the progress.
Plus there's already the "wiki".
Unless someone really wants it, and is willing to keep it up to date (I won't!) I think we should get rid of it as well.

Support 'unar' instead of requiring various unpackers (e.g. xz)

Is your feature request related to a problem? Please describe.

I'm frustrated when something requires an unpacker, such as xz.

Describe the solution you'd like

Recognize and support unar for unpacking archives.

Bonus points for adding a Zinit pack/annex (not sure which would be applicable here).

Describe alternatives you've considered

You gotta help us, Doc. We've tried nothin' and we're all out of ideas.

gh-r isn't searching for Apple Silicon compatible binaries correctly.

On my new M1 MacBookPro...

The gh-r ice isn't correctly grabbing the right binary packages that are using platform strings like x86_64-apple-darwin (usually Rust apps in my experience). e.g. ripgrep, git-delta, fd, led, and bat.

It's usually finding the linux arm binaries instead.

Here are my environment variables from zsh installed via Home-brew which is version zsh 5.8 (arm-apple-darwin21.1.0):

CPUTYPE=arm64
MACHTYPE=arm
OSTYPE=darwin21.1.0

When using /bin/zsh which is zsh 5.8 (x86_64-apple-darwin21.0):

CPUTYPE=arm64
MACHTYPE=x86_64
OSTYPE=darwin21.0
# An example command to cause the issue(s) in question.
zinit wait lucid for \
  from'gh-r' \
  as'program' \
  mv'lsd* -> lsd' \
  pick'lsd/lsd' \
  @Peltoche/lsd

I suspect the way to deal with this is to detect that it is an M1 macOS system and do an arm check then an intel type.

I don't think moving the CPUTYPE up in .zinit-get-latest-gh-r-url-part would be enough. Plus MACHTYPE won't check for amd64 unless it is /bin/zsh. A native zsh won't have any indication that it has Rosetta 2 installed and can handle amd64 binaries.

Yes, I can do experiments for you. 😃

💡 Proposal: Move doc/install.sh to another dir

While working on #43 I couldn't help but notice that the installer script is stored under doc/.

IMHO the doc/ dir should only - as the name implies - store documentation and not arbitrary scripts.

I'd like to move it to installer/install.sh or scripts/install/install.sh.
This shouldn't have many implications besides that the curl install instructions need to be updated once (and if) this is done.

Related: #55

🤖 Extend the documentation workflow

We need CI for the really boring stuff: zsdoc, manpage, PDF. Otherwise they will get out of sync. Should be fairly trivial to add.
In CI we can generate all of these and ship them to the repo.

It think these artifacts can be stored in the gh-pages branch. Keeping them as build artifacts is sadly not an option because of the max lifetime of these (90 days?). Let me know if there's a more appropriate place for these.

TODO:

  • Rename and extend the gh-pages workflow
  • Move the files living in the documentation branch (mkdocs) to the main one
  • On-push generation of the zsdoc
  • On-push generation of the PDF
  • Remove the *.adoc, zsdoc/ etc from the main branch
  • Update any link pointing to the aforementioned doc artifacts
  • Update instructions in doc/README.md

Refs:

📚 Install manpages automatically

Following #12 it now makes sense to have zinit automatically detect manages in plugins and symlink them to ZPX/man/man[1-9].

This leads the creation of a new ice nomanpages to explicitly disable that behavior (analogue to nocompletions)

TODOs:

  • zinit detects manpages if there is a myplugin.1 file in the root of the repo
  • Alternative paths get searched as well such as man/myplugin.1 or doc/man1/myplugin.1
  • no manpage gets symlinked if nomanpage is used

🏷️ Rename zinit annex repositories

This sounds scarier than it is, promised!

To improve discoverability I suggest that we rename the repositories from z-a-${annex_name} to zinit-annex-${annex_name}.
This shouldn't break anything (™) as GitHub redirects to the new repo name.

TODO:

  • Update the references to the various annexes in code
  • Update the references to the various annexes in the documentation

💡 Proposal: Merge all zinit-package repos into one

First and foremost: NICE.
Anyway here's me again, with another proposal.

To manage zinit packages more easily I'd like to merge all of the zinit-package-* repos into one single mono-repo.
Here's why:

  • the package repos only host a single package.json file
  • unlike plugins, packages do not get (git) cloned when installing them
  • it would increase zinit packages discoverability to only have to look for packages in a single repo
  • development and especially refactoring will be easier in the future. No need to update 10+ repos anymore if anything changes in the package.json format for example. (Example: zdharma-continuum/zinit-packages@630c49c)
  • the README of https://github.com/zdharma-continuum/zinit-packages would be the perfect place to put documentation about how to create a package. Currently, it is pretty much split across all the repos.

Per repo TODO:

zinit TODO:

  • Edit the URL that zinit uses to fetch package.json
  • Add depreciation notice in README.md and doc/CHANGELOG.md

Migration status:

💡 Proposal: Update the name of the "master" branch to main

As the title states. The default is king and main is the new master.

TODOs:

  • Update the zinit self-update subcommand so that is switches automagically to the new branch
  • Update the installation doc to fetch the install.sh from the main branch, instead of master

🏛 Proposal: Replace the wiki with GH wiki

Maintaining a separate web page is a pita, for me at least.

Having to update https://zdharma-continuum.github.io/zinit/wiki/ along with the NEWS section in the README (or doc/NEWS.md - see #44) is not something that will go too well in the future I believe.
It will probably get out of sync at some point, especially without CI. It may very well already be.

I don't think it is healthy to spread the documentation for zinit, especially after all that drama.
GitHub's wiki should be more than sufficient for our needs.

What do you guys think?

Add reproducible performance tests comparing zinit and other plugin managers

One of the main selling points of zinit is that it's fast. Freakishly fast. Let's provide a quantifiable look into how fast it is. The chart in the README is old + probably outdated.

This is probably best thrown in some container that you can run on your own machine? No need to spend CI cycles on this.

We should set up identical configs for Oh-My-Zsh, zplug, and zinit and track "time to usable shell".

sbin annex does not work with zsh 5.4.2

Describe the bug
A clear and concise description of what the bug is.

sbin did not create any shim in corresponding directory. But when I delete the package, zinit warns that

bin-gem-node annex: The fzf shim didn't exist in $ZPFX/bin (or isn't a regular file)

Zinit config
Steps to reproduce the behavior. Please include any relevant config section
that may help the maintainers reproduce the issue.

zinit light-mode for \
    zdharma-continuum/z-a-rust \
    zdharma-continuum/z-a-patch-dl \
    zdharma-continuum/z-a-as-monitor \
    zdharma-continuum/z-a-bin-gem-node

zinit wait lucid from"gh-r" as"null" for \
    sbin"fzf" @junegunn/fzf \
    sbin"**/fd" @sharkdp/fd \
    sbin"**/bat" @sharkdp/bat \
    sbin"**/exa" @ogham/exa

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots (optional)
If applicable, add screenshots to help explain your problem.

Versions:

  • $ZSH_VERSION == 5.4.2
  • Operating system name and version (uname -a): ubuntu 18.04

Additional context
Add any other context about the problem here.

installation error

Hello Everything is fine?

You're probably migrating the repository project and it's giving several errors in the installation, I think it's because the url zinit-zsh has changed...

🧹 Repo clean up

A few things need to be removed or altered IMHO:

Wrong handling of ZDOTDIR in install script

Describe the bug
If $ZDOTDIR is set and $ZSHRC is not, the zinit installation script (scripts/install.sh) fails to update .zshrc with an error like:

sh: 214: cannot create /home/username/.zsh: Is a directory

Zinit config
~/.zshenv

export ZDOTDIR=$HOME/.zsh

~/.zsh/.zshrc

# empty

then run

sh -c "$(curl -fsSL https://git.io/zinit-install)"

Expected behavior
Update $ZDOTDIR/.zshrc without error

Versions:

  • $ZSH_VERSION == 5.8
  • Operating system name and version (uname -a): macOS, Linux (it is not related to operating system)

🤳 Update the screenshots in the README

Right now, we feature a bunch of outdated screenshot that were taken before the rebranding to zinit and the "deletening".
The zplugin days are long over!

Can someone please take some glamour shots? Thanks!

Remove all unicode emojis / symbols from file names

Describe the bug
Zinit cannot compile annex since some of the handler files have unicode chars in their names which zcompile does not support.
I wonder if we can dance around this issue by making the compile ice dynamically rename files.

Zinit config

zinit light-mode compile'*handler' for \
     zdharma-continuum/zinit-annex-bin-gem-node

Error output

(anon):zcompile:2: can't open file: /home/pschmitt/.local/share/zinit/plugins/zdharma-continuum---zinit-annex-bin-gem-node/\M-b\M-^F\M-^Rza-bgn-atclone-handler                                         
(anon):zcompile:2: can't open file: /home/pschmitt/.local/share/zinit/plugins/zdharma-continuum---zinit-annex-bin-gem-node/\M-b\M-^F\M-^Rza-bgn-atdelete-handler                                        
(anon):zcompile:2: can't open file: /home/pschmitt/.local/share/zinit/plugins/zdharma-continuum---zinit-annex-bin-gem-node/\M-b\M-^F\M-^Rza-bgn-atload-handler                                          
(anon):zcompile:2: can't open file: /home/pschmitt/.local/share/zinit/plugins/zdharma-continuum---zinit-annex-bin-gem-node/\M-b\M-^F\M-^Rza-bgn-help-handler

🏛 Proposal: RETAB EVERYTHING!

The more I work with zinit's core the more my eyes bleed.
Some lines are absurdly long.
A few examples:

  • builtin source "${ZINIT[BIN_DIR]}/zinit-side.zsh" || { builtin print -P "${ZINIT[col-error]}ERROR:%f%b Couldn't find ${ZINIT[col-obj]}zinit-side.zsh%f%b."; return 1; }
  • (( !OPTS[opt_-q,--quiet] )) && +zinit-message "Downloading {apo}\`{url}$sname{apo}\`{rst}${${ICE[svn]+" (with Subversion)"}:-" (with curl, wget, lftp)"}{…}"
  • files=( ${(@)${(@s: :)${extract##(\!-|-\!|\!|-)}}//(#b)(((#s)|([^\\])[\\]([\\][\\])#)|((#s)|([^\\])([\\][\\])#)) /${match[2]:+$match[3]$match[4] }${match[5]:+$match[6]${(l:${#match[7]}/2::\\:):-} }} )

I get that most people don't stick to 80 chars for their code but I'd at least appreciate if we re-tabbed the zsh scripts to use 2 space chars instead of 4.

TL;DR
I'm advocating for vim: ft=zsh et ts=2 sw=2 for zinit*.zsh

.zinit-get-package error

.zinit-get-package:25: no such file or directory: /var/folders/jv/mdqy177n7sxbpqvqr55_9pwh0000gn/T/tmp.b9qfOmzv
Error: the package `fzf` couldn't be found.
.zinit-get-package:25: no such file or directory: /var/folders/jv/mdqy177n7sxbpqvqr55_9pwh0000gn/T/tmp.Z2EfO0JG
Error: the package `fzy` couldn't be found.

I got the above error, could someone help me?

💡 Proposal: Move the C module to another repo

To me at least the module deserves to be hosted in its own repo, esp. since it is neither a strict dependency of zinit, nor does it require zinit to be installed. Unix philosophy and all.

It does not make sense to have it lay around here. Even the annexes us separate repos after all.

TODO:

  • Find a fitting name for the module (maybe not "zinit-module")
  • Create a new repo w/ code and relevant README (https://github.com/zdharma-continuum/zinit-module)
  • Update zinit module build so that it fetches the source from the other repo
  • Remove the module from zinit's repo (./zmodules)
  • README.md: Link to new repo
  • Update doc/CHANGELOG.md

Related: #36

:boom: `atclone`'s exit code shoud be propagated to the parent `zinit` call

zinit currently "silently" fails when the atclone script fails:

zinit id-as"atclone-fails" atclone'echo atclone; false' for zdharma-continuum/null && echo okay || echo failed

Downloading zdharma-continuum/null... (at label: atclone-fails...)

Cloning into '/data/plugins/atclone-fails'...
▸▹▹▹▹ ███████████ OBJ: 100, , REC: 100%
No files for compilation found.
atclone
okay

The snippet above should echo failed.

📦 ziextract should rename .bzip2 files before attempting to extract

While working on zdharma-continuum/zinit-packages#2 I noticed that ziextract does detect bzip2 files correctly but ultimately fails to extract them when their suffix does not match bz2|bzip2.

This is actually a bunzip2 issue, it refuses to operate on files whose extension don't match.

bunzip2: zinit-package-apr: unknown suffix - ignored

This is easily fixable by renaming the file just before attempting the extraction. The same is already done for zx packages.

Refs:

🤔 Some ices get ignored when run non-interactively

Describe the bug
When running non-interactively, for eg with Ansible, some ices get ignored. This also happens when run with zsh -sli.
My suspicion is that there's something fishy going with zsh hooks (add-zsh-hook) in this scenario, since this is how the make ice is called.

This makes it impossible to install everything in one go.

Zinit config

# make does not get executed when running `@zinit-scheduler-burst` w/o a TTY attached
zinit light-mode as"program" make for @direnv/direnv

Refs:

gh-r does not rename downloaded binaries in some cases

Describe the bug
Does not mv gh-r downloaded files anymore (it worked with zinit ~6 month before or so, when I last used it to install a new computer)

Zinit config

          from"gh-r" as"program" mv"git-absorb* -> git-absorb" \
          load tummychow/git-absorb \

Expected behavior

I have a git-absorb command in my path, but only git-absorb-linux-x86_64 shows up

Screenshots (optional)

Downloading tummychow/git-absorb…
(Requesting `git-absorb-linux-x86_64'…)
############################################################################################################################################################################################################ 100.0%
ziextract: Successfully extracted and assigned +x chmod to the file: `git-absorb-linux-x86_64'.

All my other such lines download tar.gz and similar files and they do rename stuff, if there is a need.

Also, if I use

          from"gh-r" as"program" mv"git-absorb-* -> git-absorb" \
          load tummychow/git-absorb \

(note the minus between 'git-absorb' and the star),

then it works:

Downloading tummychow/git-absorb…
(Requesting `git-absorb-linux-x86_64'…)
############################################################################################################################################################################################################ 100.0%
ziextract: Successfully extracted and assigned +x chmod to the file: `git-absorb-linux-x86_64'.
renamed 'git-absorb-linux-x86_64' -> 'git-absorb'

Versions:

  • $ZSH_VERSION == 5.8
  • Operating system name and version (uname -a): Linux ... 5.15.0-2-amd64 #1 SMP Debian 5.15.5-1 (2021-11-26) x86_64 GNU/Linux
  • zinit update ran before sending this bugreport

Additional context
Add any other context about the problem here.

MANPATH doesn't have ~/.zinit/polaris/man, also ~/.zinit/polaris/man doesn't exist

Describe the bug
ZPFX=~/.zinit/polaris
MANPATH doesn't have $ZPFX/man, also $ZPFX/man doesn't exist.

To Reproduce

# requires the zdharma-continuum/z-a-bin-gem-node annex
# i'm also using ryaminal/z-a-meta-plugins to bring in the annexes(including the one above), but I don't anticipate this being a problem.
zinit wait'0b' lucid for \
  id-as'github-cli' from"gh-r" sbin'usr/bin/gh' atclone'ln -sf $PWD/usr/share/man/man1/* $ZPFX/man/man1' atpull'%atclone' cli/cli \
  ;

Expected behavior
Used to be that a $ZPFX/man directory was created and added to the MANPATH directory, this is the expected behavior.

Additional context
Mostly I'm just curious if anyone is familiar with why this wouldn't work? Are others seeing this directory existing and an entry in MANPATH? I've tried to look through the code but nothing is indicating the problem.

Add a catchall wiki entry to redirect to for all broken links that cannot be restored (issues...)

We should create a wiki entry named null that explains why a specific link is dead.

And lists a few hints about where to maybe find the missing info regardless:

  • google cache
  • wayback machine
  • etc

Also, it should link to "create new issue" ;)

Originally posted by @pschmitt in #47 (comment)

TODOs:

Update the default install dir

As of now the zinit installer defaults to installing stuff under $HOME/.zinit/bin - which is a bit weird (the bin part especially) and clutters the users $HOME.

A more sensible default would be $XDG_DATA_HOME/zinit (ie. $HOME/.local/share/zinit).

Related to #28

Tasks:

  • update zinit installer to install to XDG_DATA_HOME
  • update documentation
  • update the migration wiki page

💡Proposal: Migration script?

To enable an easy and painless migration for the deleted zdharma, zsh-packages, zsh-zinit and psprint repos we should consider investing the time into creating either:

  • a one of script that would edit all the remotes of any affected pługins
  • Update zinit self-update to do that perhaps?

The issues I see with either approach are the following:

  • ⚠️ we shouldn't touch the users config file(s). Depending on the setup this might be very tricky to do anyway. A plugin report should be enough.
  • is it even worth the effort? Assuming most of the user-base that's left has already done the migration manually.

Maybe we should provide a script to do this automagically.

Originally posted by @pschmitt in #28 (comment)

za-rust-atclone-handler:8

Screenshots
If applicable, add screenshots to help explain your problem.
image

Versions:

  • $ZSH_VERSION == zsh 5.0.2 (x86_64-redhat-linux-gnu)
  • Operating system name and version (uname -a): Centos 7

No matter if I install themes or plug-ins, it always prompts like this:

za-rust-atclone-handler:8: array parameter za_rust_ef created globally in function

Neither the theme nor the plugin works.

By the way, I don’t have root privileges.

Rewrite the installer

This is a follow up to #43

Installer wishlist:

  • Functions, everywhere!
  • No more color escapes sequences in the echo calls (but vars)
  • Optionally: Ask to install zsh-bin if no zsh installed (or zsh version < 5.5)
  • #45 ?

💡 Proposal: Sever the link between our forked repos and their parents

Have to admit, the title is weird.

Anyway we, zdharma-continuum, host a whole bunch of forked repos. AFAIK these were all created after the "deletening" (yes, I'm trying to make this is thing).

Some if not all of these forks have received updates. I don't think we'll ever "upstream" those changes back by opening PRs towards the original repos.
So, to improve discoverability and make our repo stand out a bit more we should IMHO get in touch with GH support to ask them to remove this "fork" relationship.

List of forks: https://github.com/orgs/zdharma-continuum/repositories?q=&type=fork&language=&sort=

TODO:

Recent clone

Hi,

I was shocked when I find the repo not syncing anymore and found your fork.

I have a recent clone of zinit with all branches. If you are interested, I can push it somewhere or send you a bundle. Just reach out for me by mail. :-D

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.