This will allow creating modules that contain only externally generated
files. For example, this is how I currently use it to generate modules
for code that is supposed to be eval'ed:
zmodule-eval() {
local -r zcommand=${${=1}[1]} ztarget=${1//[^[:alnum:]]/-}.zsh
zmodule custom-${zcommand} --use mkdir --if-command ${zcommand} \
--cmd "if [[ ! {}/${ztarget} -nt \${commands[${zcommand}]} ]]; then ${1} >! {}/${ztarget}; zcompile -UR {}/${ztarget}; fi" \
--source ${ztarget}
}
zmodule-eval 'starship init zsh'
unfunction zmodule-eval
and replace the foreground color and bold expansions by ANSI escape
codes. This should make the print calls now safe and no expansion at all
should happen as we're using `-R` -- unless the `-e` flag is given.
Fixes#521. Closes#522
as it was before a34b8dab64.
Don't make zimfw hang in the foreground waiting for git to connect to
GitHub, mainly because the waiting can take too long in case of
connection issues or no network. Also set git timeout to 30 seconds so
background check also does hang for too long, just it case.
Fixes#514
This was needed when we were using xargs, but we're already using zargs
instead for quite some time. Pro is that now common functions are reused
instead of repeated. Con (or change) is that due to that reuse, and in
favor of simplification, the warning for a module with git submodules in
degit is in a separate line from a separate print call now.
Also fix regressions from recent commits:
- Need to call _zimfw_source_zimrc twice with 1 and 2 flags instead of
with flag 3, since flag 2 must be used after module is installed or
updated.
- Need to call _zimfw_print_okay from the function that handles on-pull,
since we want to include the on-pull output in verbose mode. This
function was called just `handle` before, now it's called
_zimfw_pull_print_okay.
Still need to figure out how to return a final error code from
_zimfw_run_tool_action.
actions. Return 4 if there's a zimfw update from check-version. Don't
return a specific error code if there are module updates from check, as
it uses zargs to check all and each check runs in a separate shell. Need
to figure out how to propagate all that to a final error code.
See #503
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.
