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

112 lines
3.8 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
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
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
Add `zmodule` calls to your `.zimrc` file to define the modules to be loaded.
The modules are loaded 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
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
where &lt;url&gt; is the required repository URL or path. The following formats
are equivalent: *name*, zimfw/*name*, https://<em></em>github.com/zimfw/<em>name</em>.git
[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
By default, the module name is the last component in the &lt;url&gt;. Use the
`-n`|`--name` &lt;module&lowbar;name&gt; 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
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
* `-b`&vert;`--branch` &lt;branch&lowbar;name&gt;: Use specified branch when installing and updating the module. Overrides the tag option. Default: `master`
* `-t`&vert;`--tag` &lt;tag&lowbar;name&gt;: Use specified tag when installing and updating the module. Overrides the branch option.
* `-z`&vert;`--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
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
#### Startup 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
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
* `-f`&vert;`--fpath` &lt;path&gt;: Add specified path to `fpath`. The path is relative to the module root directory. Default: `functions`, if the subdirectory exists
* `-a`&vert;`--autoload` &lt;function&lowbar;name&gt;: Autoload specified function. Default: all valid names inside all the module specified `fpath` paths
* `-s`&vert;`--source` &lt;file&lowbar;path&gt;: Source specified file. The file path is relative 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
* `-d`&vert;`--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
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
To install new defined modules, 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
To update your modules, run:
zimfw update
To upgrade Zim, run:
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