Also moved the templates out of this repository, and into the
zimfw/install repo.
This is a second big change after introducing the plugin mechanism. This
makes installation and upgrading of Zim straightforward. Maybe the most
important aspect of having the script in a single file is not having to
manage "git repos inside git repos" (see #297), since the single file
exists by itself and is not version-controlled (with git).
I've implemented a two-stage sourcing of the file, so most of the file
is only sourced when needed (namely when calling `zimfw` with any action
other than `login-init`). The two-stage process is designed to avoid
compromising the startup speed, which is our top priority.
In an effort to help making the script maintainable, I've broken it into
small ERB templates. This also adds the ability to pre-process the Zsh
code with Ruby code. To build the script, use `make`.
so going into their ${ZIM_HOME}/modules/foo directory would be like
still being inside the Zim repo, in ${ZIM_HOME}. Don't try to update
them in this case.
This was supposed to be working before, but my ${ZIM_HOME} was not a
repo when I was still developing this locally.
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.
Closes#33, closes#138, closes#262, closes#277, closes#281.
Some discussion topics that I think are worth considering before merging
this:
- [ ] Reduce the Zim "core" to a single file?
- [ ] Simplify installation? With an installation script? (See #182)
- [ ] Put the configuration into `.zshrc` instead of a separate `.zimrc`?
(See #288)
- [ ] Rerun the Eriner/zsh-framework-benchmark?
I suggest we create individual GitHub issues/PRs to start the separate
discussions.
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.
I strongly recommend you install this from scratch in a separate
directory, instead of checking out `develop` in your current Zim
installation repo.
