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.
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
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.
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`.
Only 5% (18/342) of the themes listed under [unixorn/awesome-zsh-plugins]
are actually compatible with prompinit. Of these, [clean] also allows
being sourced directly. On the other hand, 3 others are prezto themes.
promptinit would be useful for who wants to try many themes without the
need to restart their shell session. And must be many many, so
"brute-force" starting a new shell to experiment each new theme would be
a burden! Even the cleanup feature of promptinit is still incomplete, so
you eventually get a messy prompt after trying many with it. And that's
not even a everyday use case of the average Zsh user.
So prompinit it not widely supported out there, and also not very useful
for the everyday let-me-use-my-beloved-and-carefully-customized-prompt-during-the-whole-shell-session-pleasee
scenario. It's also faster and simpler to directly just source the prompt
theme to be used, not even having to autoload promptinit and let it scan
all the others themes in fpath that won't be used.
And the Zim "philosophy" is to use fast and simple solutions.
So here we go.
Fixes#325
[unixorn/awesome-zsh-plugins]: e226f3de04/README.md (themes)
[clean]: https://github.com/BrandonRoehl/zsh-clean
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.
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.
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
Update installation instructions in README.md to use cat. Also add blank
lines at the end (instead of beginning) of template files, since they're
prepended (not appended) to existing files.
See difference of output between print and cat (zlogin having a blank
like at the end):
% print -rn "$(<zlogin)$(<test)"
#
# User configuration sourced by login shells
#
# Initialize zim
[[ -s ${ZIM_HOME}/login_init.zsh ]] && source ${ZIM_HOME}/login_init.zsh# Hello world
% cat zlogin test
#
# User configuration sourced by login shells
#
# Initialize zim
[[ -s ${ZIM_HOME}/login_init.zsh ]] && source ${ZIM_HOME}/login_init.zsh
# Hello world
Fixes#94. Fixes#280. Closes#300
For short single commands, prefer a one-liner `for` with the zsh syntax:
```
for x (foo bar) print ${x}
```
Otherwise just place `; do` on the same line as the POSIX `for ... in`:
```
for x in foo bar; do
print ${x}
done
```
Closes#268
This package is causing issues, and editing Zim to allow for use in this
'packaged' format would be a pain. Installing into your home directory
is the best method of installation.
If a file doesn't exist, "$(<nonexistent)" will write:
zsh: no such file or directory: nonexistent
to fd 2. Wrap this with a "() 2>/dev/null" to silence these outputs.
We want to prepend the initialization of zim to any current user
configurations, not append. This way zim doesn't override any manually
configured settings in the user's config files.
Eric Nielsen
Matt Hamilton
Andrés Calabrese
Brottweiler
Matt Hamilton