for the same module name. Other minor fixes:
* Show skipping already installed modules with install action and `-v`.
* Consider external module dirs when calling compile action directly, by
making sure _zimfw_source_zimrc is called first.
* Ignore return value from `zargs` with `-P`, as it's oddly returning
123 since Zsh 5.9. Maybe related to these changes:
67f932e7c5
so the code is not broken by unexpected option changes, like
setopt RC_EXPAND_PARAM
which breaks
print -R 'fpath=('${${_zfpaths#${~zpre}}:A}' ${fpath})'
in the _zimfw_build_init function, for example.
See #444.
This fixes a regression introduced in commit b1edcf34d0.
Also don't use any option after `-R` just to be safe. The zshbuiltins(1)
manual states:
> Only the -e and -n flags are recognized after -R; all other arguments
> and options are printed.
listing modules that are frozen or exernal.
Also be less colorful. And some other minor fixes: allow autoloading a
function name that starts with `-`, and add required quotes around
command subsitution (otherwise words are split).
For sake of simplicity, and also to distinguish warnings from errors.
So now we have:
* errors: output to stderr, are **not** silenced with `-q`
* warnings: output to stderr, are silenced with `-q`
* info: output to stdout, are silenced with `-q`
* solicited output (like help, info, or list): output to stdout, does
not make sense to be silenced with `-q`
We also only have warning in 3 situations so far... :- )
Using the `list` action with `-v` shows all current details for the
existing modules.
Don't try to install or update external modules, since they have an
absolute path instead of a valid URL.
and also simplify code by setting multiple variables at once. This
should make the resulting script a tiny bit smaller, while not
compromising on legibility.
Had to remove ${DIR} before renaming ${dir_new} to ${DIR}.
Also also add ${REV} to the info file, in case we need it in the future,
when extracting Zim's degit as a standalone tool for example.
and rename previous to git.
Tools allow for different install and update scripts. The git tool does
what the previous implementation did (installs and updates using the git
client). The new tool installs and updates with the GitHub API, not
using the git client, but using curl/wget and tar instead.
Closes#373
We need to fetch all branches first to handle the scenario when the HEAD
remote branch was renamed. Recently repositories started changing their
HEAD branch names from master to main.
Fixes#424
The regression was introduced in commit 3567694. I wrongly assumed that
`git fetch -pq origin HEAD` would fetch from the remote default branch.
Fixes#423
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
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.
because it was being processed as the beginning of a escape sequence.
Using `print -R` fixes that. Probably a good idea to use it when
printing other messages that contain externally-generated output.
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`.
