Giters

romkatv / zsh4humans

A turnkey configuration for Zsh

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

how to customize omz plugins

woss opened this issue · comments

commented

Hi, I'm trying to get the autoload for the nvm plugin to work.

Any idea what am I doing wrong?
Thanks

z4h load   ohmyzsh/ohmyzsh/plugins/nvm  # load a plugin
zstyle ':omz:plugins:nvm' autoload yes

# don't install zsh4humans to ssh connections
zstyle ':z4h:ssh:*' passthrough 'yes'
commented

That's the correct way to load an omz plugin.

If this plugin does not do what you expect, you can try loading it with tracing:

emulate zsh -o xtrace -c 'z4h load ohmyzsh/ohmyzsh/plugins/nvm'
commented

does this mean it is loaded?
image

What I really would like to see is that autoload working, it's so cumbersome to to nvm use all the time :)

commented

Here it didn't load because which nvm resolved into something. You can see what it resolves to by typing which nvm. If you are loading this plugin from .zshrc and then again trying to load it manually, it is expected that you'll get this output. In short, it says very little about what's going on.

commented

which nvm resolves to this. I installed it with brew install nvm and I didn't add anything to my .zshrc or .env.zsh which contains all extra stuff so I can just update z4h without thinking something will break

image
commented

That's expected. Basically, you loaded the plugin without tracing. We won't know what happened at that point because we have no trace. Then you attempted to load the plugin a second time but with tracing. This time the plugin didn't load because it was already loaded.

commented

I can just update z4h without thinking something will break

I didn't understand this point. Perhaps you believe that updating z4h with z4h update may modify your rc files? It cannot. It also cannot break anything, it's fully backward compatible until the end of times.

commented

That's expected. Basically, you loaded the plugin without tracing. We won't know what happened at that point because we have no trace. Then you attempted to load the plugin a second time but with tracing. This time the plugin didn't load because it was already loaded.

Thanks for the explanation, it makes sense, what doesn't is that i don't load it ( as far as i know) at all, maybe homebrew does some magic loading, needs investigating. Regardless, I wouldn't like to spend your time helping me with a thing that is not z4h related. 😁

Let's say i managed to load it with the z4h load ... would this zstyle ':omz:plugins:nvm' autoload yes be the way to customize it?

commented

I believe you loaded it via .zshrc. Since we don't know what happens when it gets loaded (and apparently you don't get the behavior you expect from this loading), it's a good idea to trace it while it's loading. I gave you the command above for that. Do not run that command manually. Instead, use it in .zshrc instead of the command you currently have there.

commented

nope, i triple-checked and the only homebrew-related line is eval "$($HOMEBREW_PREFIX/bin/brew shellenv)"

Now i replaced the load as you suggested and i can see this output https://gist.github.com/woss/6206d2d905f3c70fc3666cbede39435b
image

To test the autoloading, i went cd to directory that contains the .nvmrc and nothing happened.

commented

nope, i triple-checked and the only homebrew-related line is eval "$($HOMEBREW_PREFIX/bin/brew shellenv)"

Your original post here says that you have the following in .zshrc:

z4h load   ohmyzsh/ohmyzsh/plugins/nvm  # load a plugin

This loads the plugin. Since we don't know what happens when it is loaded and we would like to know that, we want to trace this call. I gave you a command that does that. You don't need to run it manually because it'll result in the plugin being loaded a second time and it's not interesting to see what happens when we load it a second time.

Now i replaced the load as you suggested and i can see this output https://gist.github.com/woss/6206d2d905f3c70fc3666cbede39435b image

Nice! This is what I've been asking for.

Now we can see that the problem is caused by zstyle being below z4h load. You can fix it by swapping the lines.

zstyle ':omz:plugins:nvm' autoload yes
z4h load ohmyzsh/ohmyzsh/plugins/nvm
commented

wow, that worked! switching the position really did the trick.

Can you please explain to me why? 🙂

commented

We can see in the trace that during loading the plugin is querying this style, so it must be set before the plugin is loaded.

commented

Note that this doesn't have anything to do with zsh4humans. It's just how this particular plugin works: it requires that you set the style before loading it.

commented

thank you so much. i hope this issue helps others to find a solution.