2018-12-12 10:40:23 -05:00
Zsh IMproved FrameWork
======================
2015-12-15 00:12:17 -05:00
2015-12-17 07:44:19 -05:00
< div align = "center" >
2018-01-01 07:58:41 -05:00
< a href = "https://github.com/zimfw/zimfw" >
2015-12-17 11:04:01 -05:00
< img width = 650px src = "https://i.eriner.me/zim_banner.png" >
2015-12-17 07:44:19 -05:00
< / a >
< / div >
2015-12-15 00:12:17 -05:00
What is Zim?
------------
2015-12-18 13:41:02 -05:00
Zim is a Zsh configuration framework with [blazing speed][speed] and modular extensions.
2015-12-17 08:06:26 -05:00
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!
2015-12-15 00:12:17 -05:00
What does Zim offer?
-----------------
2015-12-18 13:41:02 -05:00
If you're here, it means you want to see the cool shit Zim can do. Check out the [available modules][modules]!
2015-12-16 18:00:14 -05:00
Below is a brief showcase of Zim's features.
2015-12-15 00:12:17 -05:00
2015-12-18 13:41:02 -05:00
### Speed
For a speed comparison between Zim and other frameworks, see [this wiki entry][speed].
2015-12-18 13:34:24 -05:00
2015-12-18 13:41:02 -05:00
### Themes
2015-12-18 11:44:57 -05:00
2015-12-18 13:46:16 -05:00
To preview some of the available themes, check the [themes wiki page][themes].
2015-12-18 11:44:57 -05:00
2018-12-12 10:40:23 -05:00
### Fish-shell history navigation
2015-12-15 00:43:33 -05:00
![history-substring-search][fish_shell]
2015-12-15 00:12:17 -05:00
2018-12-12 10:40:23 -05:00
### Syntax highlighting
2015-12-15 00:43:33 -05:00
![syntax-highlighting][syntax_highlighting]
2015-12-15 00:12:17 -05:00
2015-12-18 13:41:02 -05:00
### And much more!
2015-12-15 00:12:17 -05:00
Zim has many modules! Enable as many or as few as you'd like.
Installation
------------
2019-01-10 19:59:04 -05:00
Installing Zim is easy:
2015-12-15 00:12:17 -05:00
2019-01-10 19:59:04 -05:00
curl -s --proto -all,+https https://raw.githubusercontent.com/zimfw/install/develop/install.zsh | zsh
2015-12-15 00:12:17 -05:00
2019-01-10 19:59:04 -05:00
Open a new terminal and you're done! Enjoy your Zsh IMproved! Take some time to
read about the [available modules][modules] and tweak your `.zshrc` file.
2015-12-15 00:12:17 -05:00
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
Settings
2016-09-05 18:36:44 -04:00
--------
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
### Enabled modules
2016-09-05 18:36:44 -04:00
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
Use the following zstyle to select the modules you would like enabled:
2016-09-05 18:36:44 -04:00
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
zstyle ':zim' modules 'first-module' 'second-module' 'third-module'
2016-09-05 18:36:44 -04:00
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
You can provide as many module names as you want. Modules are sourced in the
order given.
2016-09-05 18:36:44 -04:00
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
By default, a module is installed from the Zim repository with the same name.
2019-01-10 19:59:04 -05:00
For example, the `utility` module is installed from
https://< em > < / em > github.com/zimfw/utility.git if no additional module configuration is provided.
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
### Module customization
2019-01-10 19:59:04 -05:00
To configure a module, use the following format, where the style name is the
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
zstyle ':zim:module' < module > ['frozen' yes] ['url' < url > ] ['branch' < branch > |'tag' < tag > ]
2019-01-10 19:59:04 -05:00
| Key | Description | Default value |
| --- | ----------- | ------------- |
| frozen | If set to yes, then module will not be cleaned, installed or updated. It can still be freely enabled or disabled with the modules style. | no |
| url | Repository URL or path. The following formats are equivalent: *module* , zimfw/*module*, https://< em ></ em > github.com/zimfw/< em > module</ em > .git | *module* |
| branch | Repository branch. | master |
| tag | Repository tag. Overrides branch, if one was specified. | |
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
Choose the module name wisely. The first file found in the module root directory,
2019-01-10 19:59:04 -05:00
in the following order, will be sourced:
init.zsh, *module* .zsh, *module* .plugin.zsh, *module* .zsh.theme, *module* .sh
2016-09-05 18:36:44 -04:00
2019-01-10 19:59:04 -05:00
For example, [mafredi/zsh-async ](https://github.com/mafredri/zsh-async ) must be
configured as a module called `async` :
2016-09-05 18:36:44 -04:00
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
zstyle ':zim:module' async 'url' 'mafredri/zsh-async'
2016-09-05 18:36:44 -04:00
2019-01-10 19:59:04 -05:00
because it has an async.zsh initialization file. Then to be enabled, `async` must
be added to the modules style.
2018-12-12 10:40:23 -05:00
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
### Prompt theme
2016-09-05 18:36:44 -04:00
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
Prompt themes are enabled in one of two different ways, depending on how the
specific theme you want works:
2016-09-05 18:36:44 -04:00
2019-01-10 19:59:04 -05:00
1. If it has a prompt_< em > module</ em > _setup file: it is enabled with Zim's
`prompt` module. See [the instructions
here](https://github.com/zimfw/prompt/blob/master/README.md#settings). All
[Zim themes ](https://github.com/zimfw/zimfw/wiki/Themes ) work this way.
The advantage of these themes is that you can customize them with
additional parameters.
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
2. If it has one of the initialization files listed above: it is enabled when
2019-01-10 19:59:04 -05:00
it's sourced, not with Zim's `prompt` module. The last sourced prompt
overrides any previous ones.
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
Updating
--------
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` .
2016-09-05 18:36:44 -04:00
2015-12-17 11:04:01 -05:00
[fish_shell]: https://i.eriner.me/zim_history-substring-search.gif
[syntax_highlighting]: https://i.eriner.me/zim_syntax-highlighting.gif
2018-01-01 07:58:41 -05:00
[speed]: https://github.com/zimfw/zimfw/wiki/Speed
[modules]: https://github.com/zimfw/zimfw/wiki/Modules
[themes]: https://github.com/zimfw/zimfw/wiki/Themes