that removes the dumpfile if it's outdated, so it will get dumped again
when the shell starts next time. We're not using comdump because wrapped
ZLE widgets cannot or should not be identified by compdump when they
have a different name than the original one.
See https://github.com/zsh-users/zsh-syntax-highlighting/issues/851
Changes are:
* Don't compile in the background anymore, only via the `zimfw` tool
after actions where scripts can change (build, install, update)
* Move compilation of the completion dumpfile to the completion module:
9386a76eac/init.zsh (L10-L11)
* Don't compile users startup scripts anymore (.zshenv, .zshrc, etc.)
* Make output of `zimfw init` friendlier for the terminal startup
screen when called without `-q`.
See https://github.com/romkatv/zsh-bench/pull/11#issuecomment-994979683
and https://github.com/romkatv/zsh-bench#cutting-corners
Regarding not compiling users startup scripts anymore, I'm choosing to
only compile the modules' scripts at least for the reason that compile
won't happen so ofter anymore -- it will only happen when the user calls
the `zimfw` build, install or update actions. So it makes more sense to
only compile the files that `zimfw` has control over changes...
Closes#450
instead of allowing xargs to execute the action with no positional
parameters.
Also don't try to write to .latest_version if there's no write
permission. This is supposed to be a background/optional operation, so
we don't want to show an error message in this case.
And use Zsh globs instead of find with -exec, and find won't fail if
there's an error with the -exec command.
so the normal output is focused on the given action, and output for
additional steps perfomed after the given action is only shown in
verbose mode.
Also, the output of wget is only shown in verbose mode. This is because
wget always shows some output (to stderr) even when there are no errors.
See https://serverfault.com/q/70889/302338
This should give a friendlier output.
See #360
At least until Zsh version 5.7.1, no performance improvement is observed
out of using those.
In some cases, the performance is even worsened, like when using
autoload -w functions_digest.zwc
instead of
autoload func_name1 func_name2 ...
we want to be a universal Zsh framework, and send the message that
"less is less"! ;- )
Don't indent done and failed messages with an indicator, at the end of
actions, to differentiate them from intermediate okay and error messages.
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`.
Eric Nielsen