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

144 lines
4.5 KiB
Markdown
Raw Normal View History

Update README.md instructions and formatting Add a first step to explicitly start the Zsh shell, as some issues were reported before because users were skipping this. See #214 for example. Also mention `~/.zlogin` as part of the uninstalling process. Use the following formatting styles: * Headers >1 are in `Sentence case`. * The names `Zim` and `Zsh` always appear capitalized, even in the middle of sentences. * Prefer code indented with 4 spaces instead of ``` code fenced by lines with three back-ticks ``` Closes #315
2018-12-12 10:40:23 -05:00
Zsh IMproved FrameWork
======================
initial commit
2015-12-15 00:12:17 -05:00
Add logo
2015-12-17 07:44:19 -05:00
<div align="center">
Update to new repo URL from `Eriner/zim` to the new `zimfw/zimfw`. Closes #238
2018-01-01 07:58:41 -05:00
<a href="https://github.com/zimfw/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
<img width=650px src="https://zimfw.github.io/images/zim_banner.png">
Add logo
2015-12-17 07:44:19 -05:00
</a>
</div>
initial commit
2015-12-15 00:12:17 -05:00
What is Zim?
------------
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
Zim is a Zsh configuration framework with [blazing speed] and modular extensions.
re-word project page
2015-12-17 08:06:26 -05:00
fix typos and structure
2015-12-18 07:40:11 -05:00
Zim is very easy to customize, and comes with a rich set of modules and features without compromising on speed or functionality!
initial commit
2015-12-15 00:12:17 -05:00
What does Zim offer?
-----------------
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 you're here, it means you want to see the cool shit Zim can do. Check out the [available modules]!
add link to modules wiki article
2015-12-16 18:00:14 -05:00
Below is a brief showcase of Zim's features.
initial commit
2015-12-15 00:12:17 -05:00
update link format
2015-12-18 13:41:02 -05:00
### Speed
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
For a speed comparison between Zim and other frameworks, see [this wiki entry][blazing speed].
link to speed wiki entry
2015-12-18 13:34:24 -05:00
update link format
2015-12-18 13:41:02 -05:00
### Themes
add theme images
2015-12-18 11:44:57 -05:00
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
To preview some of the available themes, check the [themes wiki page].
add theme images
2015-12-18 11:44:57 -05:00
Update README.md instructions and formatting Add a first step to explicitly start the Zsh shell, as some issues were reported before because users were skipping this. See #214 for example. Also mention `~/.zlogin` as part of the uninstalling process. Use the following formatting styles: * Headers >1 are in `Sentence case`. * The names `Zim` and `Zsh` always appear capitalized, even in the middle of sentences. * Prefer code indented with 4 spaces instead of ``` code fenced by lines with three back-ticks ``` Closes #315
2018-12-12 10:40:23 -05:00
### Fish-shell history navigation
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
![history-substring-search]
initial commit
2015-12-15 00:12:17 -05:00
Update README.md instructions and formatting Add a first step to explicitly start the Zsh shell, as some issues were reported before because users were skipping this. See #214 for example. Also mention `~/.zlogin` as part of the uninstalling process. Use the following formatting styles: * Headers >1 are in `Sentence case`. * The names `Zim` and `Zsh` always appear capitalized, even in the middle of sentences. * Prefer code indented with 4 spaces instead of ``` code fenced by lines with three back-ticks ``` Closes #315
2018-12-12 10:40:23 -05:00
### Syntax highlighting
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
![syntax-highlighting]
initial commit
2015-12-15 00:12:17 -05:00
update link format
2015-12-18 13:41:02 -05:00
### And much more!
initial commit
2015-12-15 00:12:17 -05:00
Zim has many modules! Enable as many or as few as you'd like.
Installation
------------
Update README.md with automatic installer Also change formatting of the settings. Using `<em></em>` to prevent URL autolinking in some cases, and to add emphasis where `*foo*` would be ambiguous for the Markdown format. Copy was also slightly improved, hopefully for better clarity.
2019-01-10 19:59:04 -05:00
Installing Zim is easy:
initial commit
2015-12-15 00:12:17 -05:00
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
* With curl:
curl -fsSL https://raw.githubusercontent.com/zimfw/install/develop/install.zsh | zsh
* With wget:
wget -nv -O - https://raw.githubusercontent.com/zimfw/install/develop/install.zsh | zsh
initial commit
2015-12-15 00:12:17 -05:00
Update README.md with automatic installer Also change formatting of the settings. Using `<em></em>` to prevent URL autolinking in some cases, and to add emphasis where `*foo*` would be ambiguous for the Markdown format. Copy was also slightly improved, hopefully for better clarity.
2019-01-10 19:59:04 -05:00
Open a new terminal and you're done! Enjoy your Zsh IMproved! Take some time to
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
read about the [available modules] and tweak your `.zshrc` file.
initial commit
2015-12-15 00:12:17 -05:00
Update README.md with automatic installer Also change formatting of the settings. Using `<em></em>` to prevent URL autolinking in some cases, and to add emphasis where `*foo*` would be ambiguous for the Markdown format. Copy was also slightly improved, hopefully for better clarity.
2019-01-10 19:59:04 -05:00
If you have a different shell framework installed (like oh-my-zsh or prezto),
*uninstall those first to prevent conflicts*.
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
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
### Manual installation
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
1. Start a Zsh shell
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
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
zsh
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
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
2. Set Zsh as the default shell:
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
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
chsh -s =zsh
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
3. Copy https://raw.githubusercontent.com/zimfw/zimfw/develop/zimfw.zsh to
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
`~/.zim/zimfw.zsh`.
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
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
4. Add the lines in the following templates to the respective dot files:
* [~/.zimrc](https://github.com/zimfw/install/blob/develop/src/templates/zimrc)
* [~/.zlogin](https://github.com/zimfw/install/blob/develop/src/templates/zlogin)
* [~/.zshrc](https://github.com/zimfw/install/blob/develop/src/templates/zshrc)
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
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
5. Install the modules defined in `~/.zimrc` and build the static initialization script:
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
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
source ~/.zim/zimfw.zsh install
Add manual installation to README.md
2019-12-04 07:22:17 -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
Usage
-----
[Readme] add update and removal notes Closes #50
2016-09-05 18:36:44 -04: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
[Readme] add update and removal notes Closes #50
2016-09-05 18:36:44 -04:00
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
Add `zmodule` calls to your `~/.zimrc` file to define the modules to be initialized.
The modules are initialized in the same order they are defined. Add:
[Readme] add update and removal notes Closes #50
2016-09-05 18:36:44 -04: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 <url> [-n|--name <module_name>] [options]
[Readme] add update and removal notes Closes #50
2016-09-05 18:36:44 -04:00
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
where `<url>` is the required repository URL or path. The following formats
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
are equivalent: `name`, `zimfw/name`, `https://github.com/zimfw/name.git`.
[Readme] add update and removal notes Closes #50
2016-09-05 18:36:44 -04:00
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
By default, the module name is the last component in the `<url>`. Use the
`-n|--name <module_name>` option to set a custom module name.
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
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
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
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
* `-b|--branch <branch_name>`: Use specified branch when installing and
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
updating the module. Overrides the tag option. Default: `master`.
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
* `-t|--tag <tag_name>`: Use specified tag when installing and updating the
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
module. Overrides the branch option.
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
* `-z|--frozen`: Don't install or update the 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
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
#### Initialization options
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
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
* `-f|--fpath <path>`: Add specified path to `fpath`. The path is relative to
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
the module root directory. Default: `functions`, if the subdirectory exists.
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
* `-a|--autoload <function_name>`: Autoload specified function. Default: all
valid names inside the module's specified `fpath` paths.
* `-s|--source <file_path>`: Source specified file. The file path is relative
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
to the module root directory. Default: the file with largest size matching
`{init.zsh|module_name.{zsh|plugin.zsh|zsh-theme|sh}}`, if any exists.
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
* `-d|--disabled`: Don't use or clean the 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
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
[Readme] add update and removal notes Closes #50
2016-09-05 18:36:44 -04:00
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
Added new modules to `~/.zimrc`? Run:
[Readme] add update and removal notes Closes #50
2016-09-05 18:36:44 -04: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
zimfw install
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
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
Removed modules from `~/.zimrc`? Run:
zimfw clean-modules
Want to update your modules to their latest revisions? Run:
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
zimfw update
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
Want to upgrade `~/.zim/zimfw.zsh` to the latest version?
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
zimfw upgrade
For more information about the `zimfw` tool, run `zimfw` with no parameters.
Uninstalling
------------
The best way to remove Zim is to manually delete `~/.zim`, `~/.zimrc`, and
remove the initialization lines from your `~/.zshrc` and `~/.zlogin`.
[Readme] add update and removal notes Closes #50
2016-09-05 18:36:44 -04: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
[history-substring-search]: https://zimfw.github.io/images/zim_history-substring-search.gif
[syntax-highlighting]: https://zimfw.github.io/images/zim_syntax-highlighting.gif
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
[blazing speed]: https://github.com/zimfw/zimfw/wiki/Speed
[available modules]: https://github.com/zimfw/zimfw/wiki/Modules
[themes wiki page]: https://github.com/zimfw/zimfw/wiki/Themes
Reference in a new issue Copy permalink