Previous change fixed the old dumpfile vs. new dumpfile check, but
removed an existing (but flawled) old Zim fpath vs. new Zim fpath check.
We should be doing both checks the right way now.
Show the value of some relevant environment variables instead of calling
uname, which might show private information like the host name.
Other minor fixes regarding output.
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
first because simpler is usually better, and second because we cannot
always guarantee that the .latest_comp file, which was holding the list
of all completion functions, is consistently in sync with the dumpfile
that is generated afterwards.
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
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.
to avoid the horizontal scroll in the https://github.com/zimfw/zimfw
GitHub homepage, as GitHub made the width of the pre block further
narrower. (It's 94 characters now, was 97 before)
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).
Fix computing the list of unused modules by using the full `_zdirs`
instead of just the `_zmodules` names. The fixed code was even simpler
and cleaner, which makes it even more satisfying. :- )
Show "not found" instead of "not installed" error when an external
module dir does not exist, since we don't install external modules.
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... :- )
from the shell. This means getting
zmodule: Must be called from ${ZDOTDIR:-${HOME}}/.zimrc
and the full zmodule usage, instead of getting
zsh: command not found: zmodule
Fixes#430
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 ZIM_HOME is not. It can be reproduced with:
unset ZIM_HOME
setopt WARN_CREATE_GLOBAL
zimfw info
and the warning is:
zimfw.zsh:33: scalar parameter ZIM_HOME created globally in function zimfw
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.
that have a slash, as that yields subdirectories. For example:
zmodule duration-info -n zimfw/duration-info
zmodule git-info -n zimfw/git-info
zmodule asciiship -n zimfw/asciiship
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
`foo | sed 's?^.*/v??' | sort -n -t. -k1,1 -k2,2 -k3,3 | tail -n1` is
the same as `${${(On)${(f)"$(foo)"}##*v}[1]}`. We don't want to depend
on external tools that might not be available in all platforms.
to avoid conflicts when we have Zim modules made to also be compatible
with ohmyzsh, like https://github.com/zimfw/pvenv
We don't want to be affected by the noise a `${module_name}.plugin.zsh`
file creates, as we always want to source `init.zsh` when a module also
has a `functions` subdir. Hope this better protects us from the "wild
west out there".
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
as we do for init.zsh, so behavior is symmetric. This guarantees that
both init.zsh and login_init.zsh will always have newer timestamps than
.zimrc after a build.
gunzip should not try to seek the stream, but an issue was reported
in #407, where it fails with
gzip: stdin: unexpected end of file
So we're writing to a file first just to be safer.
Fixes#407.
Pattern must match from the beginning (`##`).
Also don't quote ${ZIM_HOME}. We don't want to have an array like
('${ZIM_HOME}' '/path/to/zim_home'), so it needs to be unquoted for the
uniqueness to work.
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.
before initial check for latest version. Not all versions of Zsh or all
OSs are affected. Error seen with Zsh 5.6.2 running on FreeBSD is:
_zimfw_version_check:10: no such file or directory: /path/to/.latest_version
Last-minute minor fixes:
* Delete .latest_version after upgrading. Having a cache brings in these
complexities.
* Print warning to stderr, to distinguish it from the normal output.
* Update help to be in sync with the README.md.
as it was being used to update the login_init.zsh script. BUT the
function mentioned, which updates that script, would only be updated
after zimfw.zsh is sourced again, so no point in trying to call it at
this point.
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
