psi-jack
/
zimfw
mirror of
1
0
Fork 0
Code Issues Releases Wiki Activity
zimfw/README.md

142 lines
5.8 KiB
Markdown
Raw Normal View History

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">
v1.0.0 Changes: * Reduce the Zim "core" to a single file * Simplify installation with an installation script (Closes #182) * Put the configuration into .zshrc instead of a separate .zimrc (Closes #288) * Do not support themes that require promptinit (See #325) * Generate a static script that does autoload the functions and source the modules This version is not backwards-compatible with previous versions, so a new installation of Zim is required.
2020-01-02 13:05:53 -05:00
<img width="650" src="https://zimfw.github.io/images/zim_banner.png">
Add logo
2015-12-17 07:44:19 -05:00
</a>
</div>
Add help and version actions
2020-01-13 12:24:43 -05:00
Zsh IMproved FrameWork
======================
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:
v1.0.0 Changes: * Reduce the Zim "core" to a single file * Simplify installation with an installation script (Closes #182) * Put the configuration into .zshrc instead of a separate .zimrc (Closes #288) * Do not support themes that require promptinit (See #325) * Generate a static script that does autoload the functions and source the modules This version is not backwards-compatible with previous versions, so a new installation of Zim is required.
2020-01-02 13:05:53 -05:00
curl -fsSL https://raw.githubusercontent.com/zimfw/install/master/install.zsh | 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
* With wget:
v1.0.0 Changes: * Reduce the Zim "core" to a single file * Simplify installation with an installation script (Closes #182) * Put the configuration into .zshrc instead of a separate .zimrc (Closes #288) * Do not support themes that require promptinit (See #325) * Generate a static script that does autoload the functions and source the modules This version is not backwards-compatible with previous versions, so a new installation of Zim is required.
2020-01-02 13:05:53 -05:00
wget -nv -O - https://raw.githubusercontent.com/zimfw/install/master/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
Optional async check for latest version every 30 days, storing it in a .latest_version file. Also allow disabling this with: zstyle ':zim' disable-version-check yes
2020-01-15 12:35:30 -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. See #33, #138, #262, #281, #324. 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.
2019-01-07 18:25:34 -05:00
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
### Manual installation
Update manual install steps to be simpler, and to teach users how to do it from outside Zsh. Users might use provioning scripts to manage their dotfiles, and knowing how to install from outside Zsh might be helpful in some cases. See #400. Closes #402
2020-06-11 22:13:55 -04:00
1. Set Zsh as the default shell:
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
Update manual install steps to be simpler, and to teach users how to do it from outside Zsh. Users might use provioning scripts to manage their dotfiles, and knowing how to install from outside Zsh might be helpful in some cases. See #400. Closes #402
2020-06-11 22:13:55 -04:00
chsh -s $(which zsh)
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
Update manual install steps to be simpler, and to teach users how to do it from outside Zsh. Users might use provioning scripts to manage their dotfiles, and knowing how to install from outside Zsh might be helpful in some cases. See #400. Closes #402
2020-06-11 22:13:55 -04:00
2. Add the lines in the following templates to the respective dot files:
v1.0.0 Changes: * Reduce the Zim "core" to a single file * Simplify installation with an installation script (Closes #182) * Put the configuration into .zshrc instead of a separate .zimrc (Closes #288) * Do not support themes that require promptinit (See #325) * Generate a static script that does autoload the functions and source the modules This version is not backwards-compatible with previous versions, so a new installation of Zim is required.
2020-01-02 13:05:53 -05:00
* [~/.zshenv](https://github.com/zimfw/install/blob/master/src/templates/zshenv)
* [~/.zshrc](https://github.com/zimfw/install/blob/master/src/templates/zshrc)
* [~/.zlogin](https://github.com/zimfw/install/blob/master/src/templates/zlogin)
* [~/.zimrc](https://github.com/zimfw/install/blob/master/src/templates/zimrc)
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
Update manual install steps to be simpler, and to teach users how to do it from outside Zsh. Users might use provioning scripts to manage their dotfiles, and knowing how to install from outside Zsh might be helpful in some cases. See #400. Closes #402
2020-06-11 22:13:55 -04:00
3. Copy https://github.com/zimfw/zimfw/releases/latest/download/zimfw.zsh to
`~/.zim/zimfw.zsh`.
4. Install the modules defined in `~/.zimrc` and build the initialization scripts:
Add manual installation to README.md
2019-12-04 07:22:17 -05:00
Update manual install steps to be simpler, and to teach users how to do it from outside Zsh. Users might use provioning scripts to manage their dotfiles, and knowing how to install from outside Zsh might be helpful in some cases. See #400. Closes #402
2020-06-11 22:13:55 -04:00
zsh ~/.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
Update zmodule usage text Hopefully the README.md will look aesthetically better with a pre block instead of switching between text and `code`.
2020-05-02 19:47:38 -04:00
<pre>
Usage: <strong>zmodule</strong> &lt;url&gt; [<strong>-n</strong>|<strong>--name</strong> &lt;module_name&gt;] [options]
[Readme] add update and removal notes Closes #50
2016-09-05 18:36:44 -04:00
Update zmodule usage text Hopefully the README.md will look aesthetically better with a pre block instead of switching between text and `code`.
2020-05-02 19:47:38 -04:00
Add <strong>zmodule</strong> calls to your <strong>~/.zimrc</strong> file to define the modules to be initialized. The modules are
initialized in the same order they are defined.
[Readme] add update and removal notes Closes #50
2016-09-05 18:36:44 -04:00
Init and compile local modules in their directories instead of requiring that they're installed inside ZIM_HOME. Fixes #399
2020-06-05 23:09:23 -04:00
&lt;url&gt; Module absolute path or repository URL. The following URL formats
are equivalent: <strong>name</strong>, <strong>zimfw/name</strong>, <strong>https://github.com/zimfw/name.git</strong>.
Update zmodule usage text Hopefully the README.md will look aesthetically better with a pre block instead of switching between text and `code`.
2020-05-02 19:47:38 -04:00
<strong>-n</strong>|<strong>--name</strong> &lt;module_name&gt; Set a custom module name. Default: the last component in the &lt;url&gt;.
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. See #33, #138, #262, #281, #324. 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.
2019-01-07 18:25:34 -05:00
Optional async check for latest version every 30 days, storing it in a .latest_version file. Also allow disabling this with: zstyle ':zim' disable-version-check yes
2020-01-15 12:35:30 -05:00
Repository options:
Update zmodule usage text Hopefully the README.md will look aesthetically better with a pre block instead of switching between text and `code`.
2020-05-02 19:47:38 -04:00
<strong>-b</strong>|<strong>--branch</strong> &lt;branch_name&gt; Use specified branch when installing and updating the module.
Overrides the tag option. Default: <strong>master</strong>.
<strong>-t</strong>|<strong>--tag</strong> &lt;tag_name&gt; Use specified tag when installing and updating the module.
Overrides the branch option.
<strong>-z</strong>|<strong>--frozen</strong> 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. See #33, #138, #262, #281, #324. 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.
2019-01-07 18:25:34 -05:00
Optional async check for latest version every 30 days, storing it in a .latest_version file. Also allow disabling this with: zstyle ':zim' disable-version-check yes
2020-01-15 12:35:30 -05:00
Initialization options:
Update zmodule usage text Hopefully the README.md will look aesthetically better with a pre block instead of switching between text and `code`.
2020-05-02 19:47:38 -04:00
<strong>-f</strong>|<strong>--fpath</strong> &lt;path&gt; Add specified path to fpath. The path is relative to the module
root directory. Default: <strong>functions</strong>, if the subdirectory exists.
<strong>-a</strong>|<strong>--autoload</strong> &lt;function_name&gt; Autoload specified function. Default: all valid names inside the
module's specified fpath paths.
<strong>-s</strong>|<strong>--source</strong> &lt;file_path&gt; Source specified file. The file path is relative to the module root
directory. Default: the file with largest size matching
<strong>{init.zsh,module_name.{zsh,plugin.zsh,zsh-theme,sh}}</strong>, if any exist.
Add `-c|--cmd` option to `zmodule` so freely defined commands can be executed. Fixes #405
2020-07-02 18:16:44 -04:00
<strong>-c</strong>|<strong>--cmd</strong> &lt;command&gt; Execute specified command. Occurrences of the <strong>{}</strong> placeholder in the
v1.3.0
2020-07-05 10:36:21 -04:00
command are substituted by the module root directory path.
Add `-c|--cmd` option to `zmodule` so freely defined commands can be executed. Fixes #405
2020-07-02 18:16:44 -04:00
<strong>-s 'script.zsh'</strong> and <strong>-c 'source {}/script.zsh'</strong> are equivalent.
Update zmodule usage text Hopefully the README.md will look aesthetically better with a pre block instead of switching between text and `code`.
2020-05-02 19:47:38 -04:00
<strong>-d</strong>|<strong>--disabled</strong> Don't initialize or uninstall the module.
</pre>
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. See #33, #138, #262, #281, #324. 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.
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
Optional async check for latest version every 30 days, storing it in a .latest_version file. Also allow disabling this with: zstyle ':zim' disable-version-check yes
2020-01-15 12:35:30 -05:00
Added new modules to `~/.zimrc`? Run `zimfw install`.
[Readme] add update and removal notes Closes #50
2016-09-05 18:36:44 -04:00
Optional async check for latest version every 30 days, storing it in a .latest_version file. Also allow disabling this with: zstyle ':zim' disable-version-check yes
2020-01-15 12:35:30 -05:00
Removed modules from `~/.zimrc`? Run `zimfw uninstall`.
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. See #33, #138, #262, #281, #324. 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.
2019-01-07 18:25:34 -05:00
Optional async check for latest version every 30 days, storing it in a .latest_version file. Also allow disabling this with: zstyle ':zim' disable-version-check yes
2020-01-15 12:35:30 -05:00
Want to update your modules to their latest revisions? Run `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
Optional async check for latest version every 30 days, storing it in a .latest_version file. Also allow disabling this with: zstyle ':zim' disable-version-check yes
2020-01-15 12:35:30 -05:00
Want to upgrade `zimfw` to its latest version? Run `zimfw upgrade`.
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
Optional async check for latest version every 30 days, storing it in a .latest_version file. Also allow disabling this with: zstyle ':zim' disable-version-check yes
2020-01-15 12:35:30 -05:00
For more information about the `zimfw` tool, run `zimfw help`.
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. See #33, #138, #262, #281, #324. 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.
2019-01-07 18:25:34 -05:00
Optional async check for latest version every 30 days, storing it in a .latest_version file. Also allow disabling this with: zstyle ':zim' disable-version-check yes
2020-01-15 12:35:30 -05:00
Settings
--------
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. See #33, #138, #262, #281, #324. 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.
2019-01-07 18:25:34 -05:00
v1.2.1
2020-05-26 09:02:25 -04:00
By default, `zimfw` will check if it has a new version available every 30 days.
Optional async check for latest version every 30 days, storing it in a .latest_version file. Also allow disabling this with: zstyle ':zim' disable-version-check yes
2020-01-15 12:35:30 -05:00
This can be disabled with:
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. See #33, #138, #262, #281, #324. 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.
2019-01-07 18:25:34 -05:00
Optional async check for latest version every 30 days, storing it in a .latest_version file. Also allow disabling this with: zstyle ':zim' disable-version-check yes
2020-01-15 12:35:30 -05:00
zstyle ':zim' disable-version-check yes
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. See #33, #138, #262, #281, #324. 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.
2019-01-07 18:25:34 -05:00
Uninstalling
------------
The best way to remove Zim is to manually delete `~/.zim`, `~/.zimrc`, and
Update README.md with new zshenv template
2019-12-14 22:41:19 -05:00
remove the initialization lines from your `~/.zshenv`, `~/.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