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.
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
so it's not a template anymore and can be under version control, instead
of being manually updated by the user, as currently is the case with
`~/.zlogin` and `${ZIM_HOME}/templates/zlogin`.
Closes#218
Consider the `zcompdump_file` variable, that could be defined in
`.zimrc`, when cleaning the cache.
A custom zcompdump_file would not be cleaned from the cache without this
correction.
Also remove *.zwc.old files from cache, as zrecompile also generates
these.
Closes#218
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
This change causes `zmanage update` to track the submodules as described
in origin/master, not from their upstream (dirty) states. Users wishing
to "revert" this change on occasion to test some upstream submodule
features, do: `cd ~/.zim && gSu`, assuming you have the git aliases.
This will pull the upstream modules to their latest state, leaving a
dirty HEAD state with these untracked modules. `cd ~/.zim && gSI` to
revert.
Closes#127
Fix `uname` calls with `-o` parameter, as this is not BSD compatible.
As per @Eriner, use `uname -a` instead as a "catch-all" parameter.
Fixes#75, Closes#79
