[Initialization] ZCompile all plugin *.zsh files and load init.sh plugins #260
Conversation
YonatanAhituv
changed the title
YonatanAhituv
changed the title
YonatanAhituv
changed the title
| @@ -36,7 +36,7 @@ fi | |||
| if [[ ! -d ${zmodule_dir} ]]; then | |||
| print "No such module \"${zmodule}\"." >&2 | |||
| else | |||
| for zmodule_file (${zmodule_dir}/init.zsh \ | |||
| for zmodule_file (${zmodule_dir}/init.{zsh,sh} \ | |||
There was a problem hiding this comment.
I think we should still only match init.zsh (not .sh) here.
| for file (${zmodule_dir}/init.zsh \ | ||
| ${zmodule_dir}/{,zsh-}${zmodule}.{zsh,plugin.zsh,zsh-theme,sh}); do | ||
| for file (${zmodule_dir}/**/*.{zsh,sh,zsh-theme} \ | ||
| ${zmodule_dir}/*.{zsh,sh,zsh-theme}); do |
There was a problem hiding this comment.
If we want to be less specific here, I think the glob should be ${zmodule_dir}/(^*test*/)#*.{zsh,zsh-theme,sh}(.N) -- don't match *test* directories (see zsh-users/zsh-syntax-highlighting#443 and #205), only match plain files, and enable NULL_GLOB in this glob (no need to do setopt and unsetopt outside).
@Eriner, what do you think? This will potentially make login_init take more time zcompiling more files.
There was a problem hiding this comment.
I don't have an issue with the zcompiling taking longer - even if it takes 2m (spoiler alert: it won't) on first run, who cares? It's smart enough that it won't redundantly zcompile unecessarily, so that penalty will only happen once and as a result every subsequent shell will load faster. Sounds like a good trade-off to me.
| for file (${zmodule_dir}/init.zsh \ | ||
| ${zmodule_dir}/{,zsh-}${zmodule}.{zsh,plugin.zsh,zsh-theme,sh}); do | ||
| for file (${zmodule_dir}/**/*.{zsh,sh,zsh-theme} \ | ||
| ${zmodule_dir}/*.{zsh,sh,zsh-theme}); do |
There was a problem hiding this comment.
Why are we zcompileing .sh files and .zsh-theme files?
There was a problem hiding this comment.
Also, globbing to zcompile all modules isn't what we want. We only want to zcompile cyclically-complex and verbose files. The reason for this is that for small files, the time to interpret and execute the .zsh file is less than the read time of the (larger) .zwc, especially on spinning disks.
zcompile is only useful for cases when interpretation is the bottleneck, and when I/O on the larger pre-compiled file is marginally better than the straight interpretation.
There was a problem hiding this comment.
Of course, we should not zcompile .sh files! 🤦♂️
What I like about this idea is that it makes zcompiling more general, and we would be also compiling extra files for whatever plugins are installed (not just extra files for syntax-highlighting or history-substring-search as we do further down). Maybe we can improve the glob by limiting by file size, like larger that 1K for example:
${zmodule_dir}/(^*test*/)#*.{zsh,zsh-theme}(.NLk+1)
(Also see my comments right below)
There was a problem hiding this comment.
Yes, I think a glob based on filesize is a good way to go about this. 👍
| # zcompile all prompt setup scripts | ||
| for file in ${ZIM_HOME}/modules/prompt/functions/prompt_*_setup; do | ||
| zrecompile -pq ${file} | ||
| done | ||
|
|
There was a problem hiding this comment.
Maybe I'm out of the loop here, but why is this removed?
There was a problem hiding this comment.
If we cover this w/ a glob based on filesize, LGTM.
Updated
login_init.zshto zcompile all patterns matching{Plugin-dir}/**/*.{zsh,sh}and{Plugin-dir}/*.{zsh,sh}.Along with a minor change, to also load
init.shplugins.This allows us to remove external plugin overrides and increase speed, along with greater compatibility with plugins like enhancd which use
init.shrather thaninit.zsh.