zdharma-continuum / zinit Goto Github PK

From:

• GitHub Releases
• zinit-packages monorepo
• Oh-My-zsh

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:

• Move files to https://github.com/zdharma-continuum/zinit-packages into a subdir named after the package name
• Update the README in the respective repo to inform users that development continues in https://github.com/zdharma-continuum/zinit-packages
• Debatable: Add deprecation notice right in the atclone ices?
• Archive the repo

zinit TODO:

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

Migration status:

• https://github.com/zdharma-continuum/zinit-package-any-gem
• https://github.com/zdharma-continuum/zinit-package-any-node
• https://github.com/zdharma-continuum/zinit-package-apr
• https://github.com/zdharma-continuum/zinit-package-asciidoctor
• https://github.com/zdharma-continuum/zinit-package-dircolors-material
• https://github.com/zdharma-continuum/zinit-package-doctoc
• https://github.com/zdharma-continuum/zinit-package-ecs-cli
• https://github.com/zdharma-continuum/zinit-package-firefox-dev
• https://github.com/zdharma-continuum/zinit-package-fzf
• https://github.com/zdharma-continuum/zinit-package-fzy
• https://github.com/zdharma-continuum/zinit-package-github-issues
• https://github.com/zdharma-continuum/zinit-package-github-issues-srv
• https://github.com/zdharma-continuum/zinit-package-ls_colors
• https://github.com/zdharma-continuum/zinit-package-pyenv
• https://github.com/zdharma-continuum/zinit-package-remark
• https://github.com/zdharma-continuum/zinit-package-svn
• https://github.com/zdharma-continuum/zinit-package-system-completions
• https://github.com/zdharma-continuum/zinit-package-zsh
• https://github.com/zdharma-continuum/zinit-package-zsh-static

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.

Currently, zinit only understands the @author/plugin syntax when loading plugins, the same should be supported for delete operations etc.

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:

• See the apr package: https://github.com/zdharma-continuum/zinit-packages/blob/main/apr/package.json

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:

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?

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.

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

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.

• https://github.com/zdharma-continuum/z-a-as-monitor -> zinit-annex-as-monitor
• https://github.com/zdharma-continuum/z-a-bin-gem-node -> zinit-annex-bin-gem-node
• https://github.com/zdharma-continuum/z-a-default-ice -> zinit-annex-default-ice
• https://github.com/zdharma-continuum/z-a-man -> zinit-annex-man
• https://github.com/zdharma-continuum/z-a-patch-dl - > zinit-annex-patch-dl
• https://github.com/zdharma-continuum/z-a-rust -> zinit-annex-rust
• https://github.com/zdharma-continuum/z-a-submods -> zinit-annex-submods
• https://github.com/zdharma-continuum/z-a-test -> zinit-annex-test
• https://github.com/zdharma-continuum/z-a-unscope -> zinit-annex-unscope

TODO:

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

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:

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

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.

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)

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)

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".

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. 😃

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.

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?

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:

• https://github.com/zdharma-continuum/zinit/runs/4275129417?check_suite_focus=true
• #96

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

• zinit/zinit-install.zsh

  Line 4 in 8b5ed2a

  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; }

• zinit/zinit-install.zsh

  Line 995 in 8b5ed2a

  (( !OPTS[opt_-q,--quiet] )) && +zinit-message "Downloading {apo}\`{url}$sname{apo}\`{rst}${${ICE[svn]+" (with Subversion)"}:-" (with curl, wget, lftp)"}{…}"

• zinit/zinit-install.zsh

  Line 1848 in 8b5ed2a

  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

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.

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.

TLDR, the following should be made possible:

zinit delete -y plugin1 plugin2 plugin3

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

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...

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.

A few things need to be removed or altered IMHO:

• To be removed: .mailmap
• To be moved: zsdoc/ to doc/
• To be renamed: doc/ -> docs/
• we should get rid of .travis.yml and run the test with Github Actions
• the tests should live in the main/master branch (they are currently on a branch: https://github.com/zdharma-continuum/zinit/tree/tests)
• the source of gh-pages should live in the main/master branch (they are currently on a branch: https://github.com/zdharma-continuum/zinit/tree/documentation)
• Rename master to main #46

.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?

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:

• https://github.com/zdharma-continuum/zsh-startify
• https://github.com/zdharma-continuum/zsh-navigation-tools
• https://github.com/zdharma-continuum/zbrowse
• https://github.com/zdharma-continuum/zzcomplete
• https://github.com/zdharma-continuum/zconvey
• https://github.com/zdharma-continuum/zui
• https://github.com/zdharma-continuum/zinit-annex-unscope
• https://github.com/zdharma-continuum/zinit-annex-submods
• https://github.com/zdharma-continuum/zinit-annex-rust
• https://github.com/zdharma-continuum/zinit-annex-patch-dl
• https://github.com/zdharma-continuum/zinit-annex-meta-plugins
• https://github.com/zdharma-continuum/zinit-annex-test
• https://github.com/zdharma-continuum/zinit-annex-bin-gem-node
• https://github.com/zdharma-continuum/zinit-annex-readurl
• https://github.com/zdharma-continuum/zservice-redis
• https://github.com/zdharma-continuum/zsh-github-issues
• https://github.com/zdharma-continuum/Zsh-100-Commits-Club
• https://github.com/zdharma-continuum/zinit-crasis
• https://github.com/zdharma-continuum/zinit-configs
• https://github.com/zdharma-continuum/zinit-console
• https://github.com/zdharma-continuum/zsh-tig-plugin
• https://github.com/zdharma-continuum/zsh-lint

Is your feature request related to a problem? Please describe.
Since at least 9ea1c9b, zinit update and self-update require GitHub credential. This was not the case before.

Describe the solution you'd like

1. Documents what GitHub permission is needed.
2. Allows alternative authentication such as tokens or remote via SSH.

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

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

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

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:

• #89
• #42
• #117

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!

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)

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).

Ah, gotcha. We should spin off a task for removing those from function names. I don't think we should have any unicode chars in the codebase except for strings we're printing for the user. It makes the code a lot harder to work with

Originally posted by @alichtman in #107 (comment)

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

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

Got an email from someone that wanted to bring this to our attention.

The now defunct zdharma[.] org redirects to a rather fishy looking domain.

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

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

We also need to standardize on a synchronous discussion platform. I set up Gitter: https://gitter.im/zdharma-continuum/community?utm_source=share-link&utm_medium=link&utm_campaign=share-link

Here's an embeddable Markdown button: [![Gitter](https://badges.gitter.im/zdharma-continuum/community.svg)](https://gitter.im/zdharma-continuum/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)

Originally posted by @alichtman in #26 (comment)

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

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

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:

• Create wiki page: https://github.com/zdharma-continuum/zinit/wiki/%F0%9F%98%95-null (be aware of the emoji in the title :))
• Update links in this repo to point to it. The OG URL should be kept as is, only the underlying link should be altered,

See zdharma-continuum/null#1 for more context

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)

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

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.

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 ?