This is a major change, where Zsh modules/plugins are not git submodules
in the Zim repo anymore, but customized and installed separately as
individual repositories. The discussion about this started more than 2
years ago in #88. Closes#299.
This will allow contributors' modules to live in their own repositories.
See #33, #138, #262, #281, #324.
The current code has what, up to this point, I considered to be the best
balance between simplicity, execution speed and number of files.
One measured decision was to make the initialization of modules depend
only on the `':zim' modules` style, keeping it as fast as possible.
The `':zim:module' module` style is used to install, update and clean
the modules, all operations that happen after the user got his
as-blazing-fast-possible shell prompt.
Even though I didn't care much about making install or update fast,
`xargs` has a nice feature of allowing commands to be executed in
parallel with `-P`. I took advantage of that.
I've also worked on making the `zimfw` utility give the user some nice
(while still minimalistic) output. Also I'm suggesting this as the new
name for the `zmanage` tool, since `zimfw` does not shadow the `zim`
wiki tool.
For short single commands, prefer a one-liner `for` with the zsh syntax:
```
for x (foo bar) print ${x}
```
Otherwise just place `; do` on the same line as the POSIX `for ... in`:
```
for x in foo bar; do
print ${x}
done
```
Closes#268
Using `bindkey` is the preferred zsh way to do it.
As far as I checked, also `set -o emacs` defines a less complete set of
key bindings compared to `bindkey -e`.
First choice is `init.zsh`, the script we use, introduced by Prezto.
Next choices are based on which are the most common init scripts in the
zsh-users repositories:
* `zsh-autosuggestions`, `zsh-history-substring-search` and
`zsh-syntax-highlighting` have `${zmodule}.zsh`
* `zsh-completions` has `${zmodule}.plugin.zsh`
Latter format apparently was introduced by Oh-My-Zsh.
Leaving `${zmodule}.zsh-theme` and `${zmodule}.sh` as the last options.
instead of a big single `functions.zwc` file containing functions from
all the `functions` subdirectories.
This solution here better suits the functions autoloading mechanism in
zsh, as documented in
http://zsh.sourceforge.net/Doc/Release/Functions.html#index-autoloading-functions
Given `~/.zim/modules/foo/functions` is in the `fpath`, autoload looks
for functions in the following files, picking the **newest one** in this
order:
* `~/.zim/modules/foo/functions.zwc`, which should contain all
functions in the directory named `functions`
* `~/.zim/modules/foo/functions/function.zwc`
* `~/.zim/modules/foo/functions/function`
With this approach, we're also having individual entries back in `fpath`
for the `functions` subdirectory of each enabled module (as was the case
before commit 55df5a4).
This is also probably closest to the original plan at #86. The current
code was not compiling "*all* files in a folder into a single digest",
but instead compiling *all* files in *all* the functions folders into a
single digest, which was a bad idea. This commit fixes this.
Fixes#231. Fixes#232. Closes#234.
Closes#239
and delete the meta module altogether.
Also refactor `tools/zim_issue` to use `tools/zim_info`, use local
variables, and print the output directly without the need of the
intermediate `issue_md` array.
Closes#218
for the autoloaded functions. According to the `zshbuiltins`
documentation:
Files containing multiple compiled functions are called `digest'
files, and are intended to be used as elements of the FPATH/fpath
special array.
Compile all module init files, instead of some selected ones.
This didn't impact performance much (time to run async block in zlogin
when from 0.22s to 0.25s on my machine).
Also refactor the zim `init.zsh` script, and do not unset `zmodules`
anymore because we need it in zlogin.
Didn't manage to make adding the prompt `prompt_*_setup` functions to
the digest file work, so kept these separate.
Fixes#86. Closes#218.
And fix init.zhs to export ZIM_HOME. The zmanage script invokes a new
shell for the sub commands, and those would fail as there would be no
value for ZIM_HOME.
Closes#203
This change allow arbitrary Zim location path by setting a new
environment variable, ZIM_HOME. If the user does not set it, Zim falls
back to the old "${ZDOTDIR:-${HOME}}/.zim" location.
Closes#203
as discussed in #184. We'll first give users this warning message. A
future update will replace this by an error.
Also, starting at that update, a new branch will be created for users
that still want to stick with zsh < 5.2.
Closes#194
