psi-jack/zimfw
1
0
Fork 0
mirror of synced 2024-11-18 05:55:34 -05:00
Code Issues Releases Wiki Activity
zimfw/zimfw.zsh

446 lines
14 KiB
Bash
Raw Normal View History

Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
# AUTOMATICALLY GENERATED FILE. EDIT ONLY THE SOURCE FILES AND THEN COMPILE.
# DO NOT DIRECTLY EDIT THIS FILE!
autoload -Uz is-at-least && if ! is-at-least 5.2; then
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
print -u2 -R "${0}: Error starting Zim. You're using Zsh version ${ZSH_VERSION} and versions < 5.2 are not supported. Update your Zsh."
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
return 1
fi
# Define Zim location
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
: ${ZIM_HOME=${0:A:h}}
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
_zimfw_compile() {
setopt LOCAL_OPTIONS EXTENDED_GLOB
autoload -U zrecompile
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
local zdumpfile zdir zfile
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
# Compile the completion cache; significant speedup
zstyle -s ':zim:completion' dumpfile 'zdumpfile' || zdumpfile="${ZDOTDIR:-${HOME}}/.zcompdump"
if [[ -f ${zdumpfile} ]]; then
zrecompile -p ${1} ${zdumpfile} || return 1
fi
# Compile .zshrc
zrecompile -p ${1} ${ZDOTDIR:-${HOME}}/.zshrc || return 1
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
# Compile autoloaded functions
for zdir in ${fpath}; do
[[ ${zdir} == (.|..) || ${zdir} == (.|..)/* ]] && continue
if [[ -w ${zdir:h} ]]; then
zrecompile -p ${1} ${zdir}.zwc ${zdir}/^(*.*)(N-.) || return 1
fi
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
done
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
# Compile scripts
for zfile in ${ZIM_HOME}/(^*test*/)#*.zsh{,-theme}(N-.); do
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
zrecompile -p ${1} ${zfile} || return 1
done
if [[ ${1} != -q ]]; then
print -P '%F{green}✓%f Done with compile.'
fi
}
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
if [[ ${1} == (compile|login-init) && ${2} == (|-q) ]]; then
_zimfw_compile ${2}
return
fi
_zimfw_build() {
() {
local -r ztarget=${ZIM_HOME}/init.zsh
Add zimfw init action for a quick build Having to manually do `zimfw build` every time after you edit your .zimrc file is boring. So by having the following in .zshrc before sourcing init.zsh will do a quick build automatically when needed: if [[ ~/.zim/init.zsh -ot ~/.zimrc ]]; then source ~/.zim/zimfw.zsh init -q fi
2019-12-07 21:17:40 -05:00
if [[ ${ztarget} -nt ${ZDOTDIR:-${HOME}}/.zimrc ]] && command cmp -s ${ztarget} ${1}; then
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
if (( ! _zquiet )); then
print -PR "%F{green}✓%f %B${ztarget}:%b Already up to date"
fi
else
if [[ -e ${ztarget} ]]; then
command mv -f ${ztarget}{,.old} || return 1
fi
command mv -f ${1} ${ztarget} && \
if (( ! _zquiet )); then
print -PR "%F{green}✓%f %B${ztarget}:%b Updated. Restart your terminal for changes to take effect."
fi
fi
if (( ! _zquiet )); then
print -P '%F{green}✓%f Done with build.'
fi
} =(
print -R "zimfw() { source ${ZIM_HOME}/zimfw.zsh \"\${@}\" }"
(( ${#_zfpaths} )) && print -R 'fpath=('${_zfpaths:P}' ${fpath})'
(( ${#_zfunctions} )) && print -R 'autoload -Uz '${_zfunctions}
print -Rn ${(F):-source ${^_zscripts:P}}
)
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
}
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
zmodule() {
local -r zusage="
Usage: %B${0}%b <url> [%B-n%b|%B--name%b <module_name>] [options]
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
Repository options:
%B-b%b|%B--branch%b <branch_name> Use specified branch when installing and updating the module
%B-t%b|%B--tag%b <tag_name> Use specified tag when installing and updating the module
%B-z%b|%B--frozen%b Don't install or update the module
Startup options:
%B-f%b|%B--fpath%b <path> Add specified path to fpath
%B-a%b|%B--autoload%b <function_name> Autoload specified function
%B-s%b|%B--source%b <file_path> Source specified file
%B-d%b|%B--disabled%b Don't use or clean the module
"
if [[ ${${funcfiletrace[1]%:*}:t} != .zimrc ]]; then
print -u2 -PR "%F{red}${0}: Must be called from ${ZDOTDIR:-${HOME}}/.zimrc%f"$'\n'${zusage}
return 1
fi
if (( ! # )); then
print -u2 -PR "%F{red}✗ ${funcfiletrace[1]}: Missing zmodule url%f"
_zfailed=1
return 1
fi
setopt LOCAL_OPTIONS EXTENDED_GLOB
local zmodule=${1:t} zurl=${1}
local ztype=branch zrev=master
local -i zdisabled=0 zfrozen=0
local -a zfpaths zfunctions zscripts
local zarg
if [[ ${zurl} =~ ^[^:/]+: ]]; then
zmodule=${zmodule%.git}
elif [[ ${zurl} != /* ]]; then
# Count number of slashes
case ${#zurl//[^\/]/} in
0) zurl="https://github.com/zimfw/${zurl}.git" ;;
1) zurl="https://github.com/${zurl}.git" ;;
esac
fi
shift
if [[ ${1} == (-n|--name) ]]; then
if (( # < 2 )); then
print -u2 -PR "%F{red}✗ ${funcfiletrace[1]}:%B${zmodule}:%b Missing argument for zmodule option ${1}%f"
_zfailed=1
return 1
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
fi
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
shift
zmodule=${1}
shift
fi
local -r zdir=${ZIM_HOME}/modules/${zmodule}
while (( # > 0 )); do
case ${1} in
-b|--branch|-t|--tag|-f|--fpath|-a|--autoload|-s|--source)
if (( # < 2 )); then
print -u2 -PR "%F{red}✗ ${funcfiletrace[1]}:%B${zmodule}:%b Missing argument for zmodule option ${1}%f"
_zfailed=1
return 1
fi
;;
esac
case ${1} in
-b|--branch)
shift
ztype=branch
zrev=${1}
;;
-t|--tag)
shift
ztype=tag
zrev=${1}
;;
-z|--frozen) zfrozen=1 ;;
-f|--fpath)
shift
zarg=${1}
[[ ${zarg} != /* ]] && zarg=${zdir}/${zarg}
zfpaths+=(${zarg})
;;
-a|--autoload)
shift
zfunctions+=(${1})
;;
-s|--source)
shift
zarg=${1}
[[ ${zarg} != /* ]] && zarg=${zdir}/${zarg}
zscripts+=(${zarg})
;;
-d|--disabled) zdisabled=1 ;;
*)
print -u2 -PR "%F{red}✗ ${funcfiletrace[1]}:%B${zmodule}:%b Unknown zmodule option ${1}%f"
_zfailed=1
return 1
;;
esac
shift
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
done
Source .zimrc twice when installing/updating Once before installing/updating to prepare _zmodule_xargs, and once after modules are updated, so functions and scripts can be found inside them. Installation of Zim from scratch was failing because all modules are empty at first.
2019-12-03 07:07:59 -05:00
if (( _zprepare_xargs )); then
if (( ! zfrozen )); then
_zmodules_xargs+=${zmodule}$'\0'${zdir}$'\0'${zurl}$'\0'${ztype}$'\0'${zrev}$'\0'${_zquiet}$'\0'
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
fi
Source .zimrc twice when installing/updating Once before installing/updating to prepare _zmodule_xargs, and once after modules are updated, so functions and scripts can be found inside them. Installation of Zim from scratch was failing because all modules are empty at first.
2019-12-03 07:07:59 -05:00
else
if (( zdisabled )); then
_zdisableds+=(${zmodule})
else
Add zimfw init action for a quick build Having to manually do `zimfw build` every time after you edit your .zimrc file is boring. So by having the following in .zshrc before sourcing init.zsh will do a quick build automatically when needed: if [[ ~/.zim/init.zsh -ot ~/.zimrc ]]; then source ~/.zim/zimfw.zsh init -q fi
2019-12-07 21:17:40 -05:00
if [[ ! -d ${zdir} ]]; then
print -u2 -PR "%F{red}✗ ${funcfiletrace[1]}:%B${zmodule}:%b Not installed%f"
_zfailed=1
return 1
fi
Source .zimrc twice when installing/updating Once before installing/updating to prepare _zmodule_xargs, and once after modules are updated, so functions and scripts can be found inside them. Installation of Zim from scratch was failing because all modules are empty at first.
2019-12-03 07:07:59 -05:00
(( ! ${#zfpaths} )) && zfpaths+=(${zdir}/functions(NF))
if (( ! ${#zfunctions} )); then
# _* functions are autoloaded by compinit
# prompt_*_setup functions are autoloaded by promptinit
zfunctions+=(${^zfpaths}/^(*.*|_*|prompt_*_setup)(N-.:t))
fi
if (( ! ${#zscripts} )); then
zscripts+=(${zdir}/(init.zsh|${zmodule:t}.(zsh|plugin.zsh|zsh-theme|sh))(NOL[1]))
fi
_zfpaths+=(${zfpaths})
_zfunctions+=(${zfunctions})
_zscripts+=(${zscripts})
_zmodules+=(${zmodule})
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
fi
fi
}
_zimfw_source_zimrc() {
Source .zimrc twice when installing/updating Once before installing/updating to prepare _zmodule_xargs, and once after modules are updated, so functions and scripts can be found inside them. Installation of Zim from scratch was failing because all modules are empty at first.
2019-12-03 07:07:59 -05:00
local -ri _zprepare_xargs=${1}
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
local -i _zfailed=0
if ! source ${ZDOTDIR:-${HOME}}/.zimrc || (( _zfailed )); then
print -u2 -PR "%F{red}✗ Failed to source ${ZDOTDIR:-${HOME}}/.zimrc%f"
return 1
fi
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
}
_zimfw_clean_modules() {
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
local zopt zdir zmodule
(( ! _zquiet )) && zopt='-v'
for zdir in ${ZIM_HOME}/modules/*(N/); do
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
zmodule=${zdir:t}
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
# If _zmodules and _zdisableds do not contain the zmodule
if (( ! ${_zmodules[(I)${zmodule}]} && ! ${_zdisableds[(I)${zmodule}]} )); then
command rm -rf ${zopt} ${zdir} || return 1
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
fi
done
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
if (( ! _zquiet )); then
print -P '%F{green}✓%f Done with clean-modules.'
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
fi
}
_zimfw_clean_compiled() {
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
local zopt_find zopt_rm zdir
if (( ! _zquiet )); then
zopt_find='-print'
zopt_rm='-v'
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
fi
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
for zdir in ${fpath}; do
[[ ${zdir} == (.|..) || ${zdir} == (.|..)/* ]] && continue
if [[ -w ${zdir:h} ]]; then
command rm -f ${zopt_rm} ${zdir}.zwc{,.old} || return 1
fi
done
command find ${ZIM_HOME} \( -name '*.zwc' -o -name '*.zwc.old' \) -delete ${zopt_find} || return 1
command rm -f ${zopt_rm} ${ZDOTDIR:-${HOME}}/.zshrc.zwc{,.old} || return 1
if (( ! _zquiet )); then
print -P '%F{green}✓%f Done with clean-compiled. Run %Bzimfw compile%b to re-compile.'
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
fi
}
_zimfw_clean_dumpfile() {
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
local zdumpfile zopt
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
zstyle -s ':zim:completion' dumpfile 'zdumpfile' || zdumpfile="${ZDOTDIR:-${HOME}}/.zcompdump"
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
(( ! _zquiet )) && zopt='-v'
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
command rm -f ${zopt} ${zdumpfile}{,.zwc{,.old}} || return 1
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
if (( ! _zquiet )); then
print -P '%F{green}✓%f Done with clean-dumpfile. Restart your terminal to dump an updated configuration.'
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
fi
}
_zimfw_info() {
Add zimfw init action for a quick build Having to manually do `zimfw build` every time after you edit your .zimrc file is boring. So by having the following in .zshrc before sourcing init.zsh will do a quick build automatically when needed: if [[ ~/.zim/init.zsh -ot ~/.zimrc ]]; then source ~/.zim/zimfw.zsh init -q fi
2019-12-07 21:17:40 -05:00
print 'Zim version: 1.0.0-SNAPSHOT (previous commit is c330f61)'
Compile also after upgrade, add ZIM_HOME to info We want to recompile zimfw.zsh if it changes. ZIM_HOME is not required to be set beforehand anymore, so let's give the users the variable info back.
2019-12-05 13:51:34 -05:00
print -R 'ZIM_HOME: '${ZIM_HOME}
print -R 'Zsh version: '${ZSH_VERSION}
print -R 'System info: '$(command uname -a)
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
}
_zimfw_upgrade() {
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
local -r zscript=${ZIM_HOME}/zimfw.zsh
local -r zurl=https://raw.githubusercontent.com/zimfw/zimfw/develop/zimfw.zsh
{
if (( ${+commands[wget]} )); then
command wget -nv ${1} -O ${zscript}.new ${zurl} || return 1
else
command curl -fsSL -o ${zscript}.new ${zurl} || return 1
fi
if command cmp -s ${zscript}{,.new}; then
if (( ! _zquiet )); then
print -P '%F{green}✓%f %Bzimfw.zsh:%b Already up to date'
fi
else
command mv -f ${zscript}{,.old} && command mv -f ${zscript}{.new,} && \
if (( ! _zquiet )); then
print -P '%F{green}✓%f %Bzimfw.zsh:%b Upgraded. Restart your terminal for changes to take effect.'
fi
fi
if (( ! _zquiet )); then
print -P '%F{green}✓%f Done with upgrade.'
fi
} always {
command rm -f ${zscript}.new
}
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
}
zimfw() {
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
local -r zusage="
Usage: %B${0}%b <action> [%B-q%b]
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
Actions:
Compile also after upgrade, add ZIM_HOME to info We want to recompile zimfw.zsh if it changes. ZIM_HOME is not required to be set beforehand anymore, so let's give the users the variable info back.
2019-12-05 13:51:34 -05:00
%Bbuild%b Build init.zsh
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
%Bclean%b Clean all (see below)
%Bclean-modules%b Clean unused modules
%Bclean-compiled%b Clean Zsh compiled files
%Bclean-dumpfile%b Clean completion dump file
%Bcompile%b Compile Zsh files
%Binfo%b Print Zim and system info
%Binstall%b Install new modules
%Bupdate%b Update current modules
Compile also after upgrade, add ZIM_HOME to info We want to recompile zimfw.zsh if it changes. ZIM_HOME is not required to be set beforehand anymore, so let's give the users the variable info back.
2019-12-05 13:51:34 -05:00
%Bupgrade%b Upgrade zimfw.zsh
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
Options:
%B-q%b Quiet, only outputs errors
"
local ztool _zmodules_xargs
local -a _zdisableds _zmodules _zfpaths _zfunctions _zscripts
local -i _zquiet=0
if (( # > 2 )); then
print -u2 -PR "%F{red}${0}: Too many options%f"$'\n'${zusage}
return 1
elif (( # > 1 )); then
case ${2} in
-q) _zquiet=1 ;;
*)
print -u2 -PR "%F{red}${0}: Unknown option ${2}%f"$'\n'${zusage}
return 1
;;
esac
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
fi
case ${1} in
install)
ztool="# This runs in a new shell
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
readonly MODULE=\${1}
readonly DIR=\${2}
readonly URL=\${3}
readonly REV=\${5}
readonly -i QUIET=\${6}
readonly CLEAR_LINE=$'\E[2K\r'
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
if [[ -e \${DIR} ]]; then
# Already exists
return 0
fi
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
(( ! QUIET )) && print -Rn \${CLEAR_LINE}\"Installing \${MODULE} …\"
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
if ERR=\$(command git clone -b \${REV} -q --recursive \${URL} \${DIR} 2>&1); then
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
if (( ! QUIET )); then
print -PR \${CLEAR_LINE}\"%F{green}✓%f %B\${MODULE}:%b Installed\"
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
fi
else
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
print -u2 -PR \${CLEAR_LINE}\"%F{red}✗ %B\${MODULE}:%b Error during git clone%f\"$'\n'\${(F):- \${(f)^ERR}}
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
return 1
fi
"
;;
update)
ztool="# This runs in a new shell
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
readonly MODULE=\${1}
readonly DIR=\${2}
readonly URL=\${3}
readonly TYPE=\${4}
readonly REV=\${5}
readonly -i QUIET=\${6}
readonly CLEAR_LINE=$'\E[2K\r'
(( ! QUIET )) && print -Rn \${CLEAR_LINE}\"Updating \${MODULE} …\"
if ! builtin cd \${DIR} 2>/dev/null; then
print -u2 -PR \${CLEAR_LINE}\"%F{red}✗ %B\${MODULE}:%b Not installed%f\"
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -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.
return 0
fi
if [[ \${URL} != \$(command git config --get remote.origin.url) ]]; then
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
print -u2 -PR \${CLEAR_LINE}\"%F{red}✗ %B\${MODULE}:%b URL does not match. Expected \${URL}. Will not try to update.%f\"
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
return 1
fi
if [[ \${TYPE} == tag ]]; then
if [[ \${REV} == \$(command git describe --tags --exact-match 2>/dev/null) ]]; then
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
(( ! QUIET )) && print -PR \${CLEAR_LINE}\"%F{green}✓%f %B\${MODULE}:%b Already up to date\"
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
return 0
fi
fi
if ! ERR=\$(command git fetch -pq origin \${REV} 2>&1); then
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
print -u2 -PR \${CLEAR_LINE}\"%F{red}✗ %B\${MODULE}:%b Error during git fetch%f\"$'\n'\${(F):- \${(f)^ERR}}
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
return 1
fi
if [[ \${TYPE} == branch ]]; then
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
LOG_REV=\${REV}@{u}
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
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
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
print -u2 -PR \${CLEAR_LINE}\"%F{red}✗ %B\${MODULE}:%b Error during git checkout%f\"$'\n'\${(F):- \${(f)^ERR}}
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
return 1
fi
if [[ \${TYPE} == branch ]]; then
if ! OUT=\$(command git merge --ff-only --no-progress -n 2>&1); then
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
print -u2 -PR \${CLEAR_LINE}\"%F{red}✗ %B\${MODULE}:%b Error during git merge%f\"$'\n'\${(F):- \${(f)^OUT}}
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
return 1
fi
# keep just first line of OUT
OUT=\${OUT%%($'\n'|$'\r')*}
else
OUT=\"Updating to \${TYPE} \${REV}\"
fi
if ERR=\$(command git submodule update --init --recursive -q 2>&1); then
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
if (( ! QUIET )); then
[[ -n \${LOG} ]] && OUT=\${OUT}$'\n'\${(F):- \${(f)^LOG}}
print -PR \${CLEAR_LINE}\"%F{green}✓%f %B\${MODULE}:%b \${OUT}\"
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
fi
else
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
print -u2 -PR \${CLEAR_LINE}\"%F{red}✗ %B\${MODULE}:%b Error during git submodule update%f\"$'\n'\${(F):- \${(f)^ERR}}
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
return 1
fi
"
;;
esac
case ${1} in
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
build) _zimfw_source_zimrc && _zimfw_build && _zimfw_compile ${2} ;;
Add zimfw init action for a quick build Having to manually do `zimfw build` every time after you edit your .zimrc file is boring. So by having the following in .zshrc before sourcing init.zsh will do a quick build automatically when needed: if [[ ~/.zim/init.zsh -ot ~/.zimrc ]]; then source ~/.zim/zimfw.zsh init -q fi
2019-12-07 21:17:40 -05:00
init) _zimfw_source_zimrc && _zimfw_build ;;
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
clean)
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
_zimfw_source_zimrc && \
_zimfw_clean_modules && \
_zimfw_clean_compiled && \
_zimfw_clean_dumpfile
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
;;
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
clean-modules) _zimfw_source_zimrc && _zimfw_clean_modules ;;
clean-compiled) _zimfw_clean_compiled ;;
clean-dumpfile) _zimfw_clean_dumpfile ;;
compile|login-init) _zimfw_source_zimrc && _zimfw_compile ${2} ;;
info) _zimfw_info ;;
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
install|update)
Source .zimrc twice when installing/updating Once before installing/updating to prepare _zmodule_xargs, and once after modules are updated, so functions and scripts can be found inside them. Installation of Zim from scratch was failing because all modules are empty at first.
2019-12-03 07:07:59 -05:00
_zimfw_source_zimrc 1 || return 1
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
print -Rn ${_zmodules_xargs} | xargs -0 -n6 -P10 zsh -c ${ztool} ${1} && \
if (( ! _zquiet )); then
print -PR "%F{green}✓%f Done with ${1}. Restart your terminal for any changes to take effect."
fi && \
Source .zimrc twice when installing/updating Once before installing/updating to prepare _zmodule_xargs, and once after modules are updated, so functions and scripts can be found inside them. Installation of Zim from scratch was failing because all modules are empty at first.
2019-12-03 07:07:59 -05:00
_zimfw_source_zimrc && _zimfw_build && _zimfw_compile ${2}
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
;;
Compile also after upgrade, add ZIM_HOME to info We want to recompile zimfw.zsh if it changes. ZIM_HOME is not required to be set beforehand anymore, so let's give the users the variable info back.
2019-12-05 13:51:34 -05:00
upgrade) _zimfw_upgrade && _zimfw_compile ;;
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
*)
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
print -u2 -PR "%F{red}${0}: Unknown action ${1}%f"$'\n'${zusage}
Zim script in a single file \o/ 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`.
2019-01-22 19:40:43 -05:00
return 1
;;
esac
}
Generate static init.zsh script \o/ to autoloads the functions and sources the scripts, instead of executing zimfw during startup, and having it always figuring out what do to on the fly. This takes out the worry about zimfw interfering with the startup time, and allows room to add more features to it. So, zstyle was replaced by a custom zmodule function to define the modules, with the extra ability of allowing users to set custom fpath paths, autoloaded functions and sourced scripts per module.
2019-12-01 16:00:47 -05:00
zimfw "${@}"
Reference in a new issue Copy permalink