1
0
Fork 0
mirror of synced 2024-06-17 06:11:09 -04:00
zimfw/src/tools/update.zsh.erb

62 lines
1.9 KiB
Plaintext
Raw Normal View History

Add a plugin mechanism \o/ 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.
2019-01-07 18:25:34 -05:00
# This runs in a new shell
DIR=${1}
URL=${2}
Add a plugin mechanism \o/ 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.
2019-01-07 18:25:34 -05:00
TYPE=${3}
REV=${4}
OPT=${5}
MODULE=${DIR:t}
CLEAR_LINE="\033[2K\r"
[[ ${OPT} != -q ]] && print -n "${CLEAR_LINE}Updating ${MODULE} …"
Add a plugin mechanism \o/ 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.
2019-01-07 18:25:34 -05:00
if ! cd ${DIR} 2>/dev/null; then
print -P "${CLEAR_LINE}%F{red}✗ ${MODULE}: Not installed%f"
Add a plugin mechanism \o/ 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.
2019-01-07 18:25:34 -05:00
return 1
fi
if [[ ${PWD} != $(command git rev-parse --show-toplevel 2>/dev/null) ]]; then
# Not in repo root. Will not try to update.
Add a plugin mechanism \o/ 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.
2019-01-07 18:25:34 -05:00
return 0
fi
if [[ ${URL} != $(command git config --get remote.origin.url) ]]; then
print -P "${CLEAR_LINE}%F{red}✗ ${MODULE}: URL does not match. Expected ${URL}. Will not try to update.%f"
Add a plugin mechanism \o/ 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.
2019-01-07 18:25:34 -05:00
return 1
fi
if [[ ${TYPE} == tag ]]; then
Add a plugin mechanism \o/ 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.
2019-01-07 18:25:34 -05:00
if [[ ${REV} == $(command git describe --tags --exact-match 2>/dev/null) ]]; then
[[ ${OPT} != -q ]] && print -P "${CLEAR_LINE}%F{green}✓%f ${MODULE}: Already up to date"
Add a plugin mechanism \o/ 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.
2019-01-07 18:25:34 -05:00
return 0
fi
fi
if ! ERR=$(command git fetch -pq origin ${REV} 2>&1); then
print -P "${CLEAR_LINE}%F{red}✗ ${MODULE}: Error (1)%f\n${ERR}"
Add a plugin mechanism \o/ 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.
2019-01-07 18:25:34 -05:00
return 1
fi
if [[ ${TYPE} == branch ]]; then
Add a plugin mechanism \o/ 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.
2019-01-07 18:25:34 -05:00
LOG_REV="${REV}@{u}"
else
LOG_REV=${REV}
fi
LOG=$(command git log --graph --color --format='%C(yellow)%h%C(reset) %s %C(cyan)(%cr)%C(reset)' ..${LOG_REV} 2>/dev/null)
if ! ERR=$(command git checkout -q ${REV} -- 2>&1); then
print -P "${CLEAR_LINE}%F{red}✗ ${MODULE}: Error (2)%f\n${ERR}"
Add a plugin mechanism \o/ 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.
2019-01-07 18:25:34 -05:00
return 1
fi
if [[ ${TYPE} == branch ]]; then
Add a plugin mechanism \o/ 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.
2019-01-07 18:25:34 -05:00
if ! OUT=$(command git merge --ff-only --no-progress -n 2>&1); then
print -P "${CLEAR_LINE}%F{red}✗ ${MODULE}: Error (3)%f\n${OUT}"
Add a plugin mechanism \o/ 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.
2019-01-07 18:25:34 -05:00
return 1
fi
# keep just first line of OUT
OUT=${OUT%%($'\n'|$'\r')*}
else
OUT="Updating to ${TYPE} ${REV}"
fi
[[ -n ${LOG} ]] && OUT="${OUT}
${LOG}"
Add a plugin mechanism \o/ 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.
2019-01-07 18:25:34 -05:00
if ERR=$(command git submodule update --init --recursive -q 2>&1); then
if [[ ${OPT} != -q ]]; then
print -R "$(print -P "${CLEAR_LINE}%F{green}✓%f") ${MODULE}: ${OUT}"
Add a plugin mechanism \o/ 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.
2019-01-07 18:25:34 -05:00
fi
else
print -P "${CLEAR_LINE}%F{red}✗ ${MODULE}: Error (4)%f\n${ERR}"
Add a plugin mechanism \o/ 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.
2019-01-07 18:25:34 -05:00
return 1
fi