Update to docs still pending hence the WIP badge

!>If you are not using a framework, or if on starting your shell you get an error message like command not found: compinit, then add the below line before the ones above.

Should probably instruct users to do this after sourcing asdf.sh as it adds to fpath, not before asdf.sh like it does now

@andrewthauer @Strayer Could you test and review to ensure these changes do as you expect and resolve any performance issues you may have seen? Thanks

Works great for me, I now only source asdf.sh in my .zshrc and let zinit handle the rest. Loads MUCH quicker and completions work as expected. Thank you @jthegedus! Any way to donate you a beer/coffee/tea/whateveryoulove?

I should point out that I noticed the following error could still occur if a user is sourcing the bash completions manually and using zsh (instead of bash):

asdf/completions/asdf.bash:68: command not found: complete

I have a script that wraps the asdf initialization that is intended to work with both zsh and bash. I was previously always sourcing the bash completions, but sine v0.77, I started getting this error as well. This was easily worked around by conditionally checking if the session is bash before sourcing. However, this leads me to think this could have started for some others as well. However, you could view this as a separate issue. I don't see these PR changes having any effect on this either way.

However, this leads me to think this could have started for some others as well.

That was exactly what I was doing and got me to even look up the issue here. I think it is reasonable to assume that sourcing a file that specifically states bash may not work in zsh, but maybe a warning in that file when it is run inside zsh might make sense.

I think it is reasonable to assume that sourcing a file that specifically states bash may not work in zsh, but maybe a warning in that file when it is run inside zsh might make sense.

Exactly. It didn't affect anything noticeable, which is why I probably didn't think twice about it. I did start seeing it in v0.77 though. I would say my fix is not a workaround and is the proper course of action. Maybe it should be noted to not source the bash completions if your using zsh? Not sure on where this actually stems from.

I should point out that I noticed the following error could still occur if a user is sourcing the bash completions manually and using zsh (instead of bash):

Given we were advising people to manually source the .bash completions before v0.7.7 (and we were running bashcompinit automatically)I think this will be a common issue. I shall update the docs to point people in the right direction. Thanks for pointing this out 🎉

docs before v0.7.7:

• https://github.com/asdf-vm/asdf/pull/544/files#diff-bb5d293cc2573b1db2aad9d78bca7be6L85
• https://github.com/asdf-vm/asdf/pull/544/files#diff-bb5d293cc2573b1db2aad9d78bca7be6L97

Anyone have feelings on how we should handle deprecating things like https://github.com/ohmyzsh/ohmyzsh/blob/master/plugins/asdf/asdf.plugin.zsh as they are now doing needless work?

Thank you @jthegedus! Any way to donate you a beer/coffee/tea/whateveryoulove?

@Strayer thanks, but I am yet to setup GitHub sponsors yet. Has been on my backlog since the beta 😅

The more I get into the weeds of this the more I think we should not be adding things to the fpath at all 🤔

We recommend sourcing asdf.sh after ZSH frameworks, but if the framework calls compinit, then the addition to fpath isn't picked up, so users would have to run compinit themselves anyway. But then plugins may exist for the framework that does integrate the sourcing of asdf.sh at the correct time in the lifecycle. There are infinite combinations here.

So I think the solution here is to:

• update ZSH framework plugins to add completions to fpath to properly integrate with their lifecycle and usage of compinit. oh-my-zsh asdf plugin needs updating, I'm sure others exist. A note in the docs might suffice here.
• update Brew installation to use the native ZSH completions - Homebrew/homebrew-core#51720
• update documentation for completions to direct people to either roll their own compinit OR if using a framework, ensure there's an asdf plugin which integrates it correctly

Thoughts anyone? @nomasprime @philpennock?

Documenting required steps and otherwise not doing anything WFM. Packagers can drop the completion into whatever directory their system sets up for such things (Homebrew/whatever), power-users who bypass such things can read the docs.

As a power use myself, I already have the expectation of manually appending things to the fpath. I've also had to factor in the lifecycle when modifying the fpath. Therefore, this strategy makes perfect sense to me and seems consistent with how many other libraries deal with zsh completions.

For reference:

• homebrew installed packages typically symlink their completions to [brew-prefix]/share/zsh/site-functions. If a user or framework adds this to their fpath (as I do), they will get completions for all that comply to that convention. See https://docs.brew.sh/Shell-Completion
• zsh-completions is a prominent project that adds zsh completions for many utilities. Their instructions tell users to add to the fpath manually as well.

Thanks for weighing in @philpennock

Thanks for the information @andrewthauer

Then Homebrew ZSH change has been merged, so users installing with Homebrew should get the correct ZSH completions through that. I will update the docs to reflect this.

I will try the symlink method used by zsh-completions in the oh-my-zsh asdf plugin and see if we can remove the usage of the bash completions there.

And I will update the docs for the rest of people using other ZSH frameworks about manual fpath setup or looking at the aforementioned plugins to update their own ecosystems.

Thanks for all your input everyone.

@Stratus3D Perhaps once I get this fix in we can organise a patch release so others don't run into these same issues?

The call to compinit will still be removed, right ?

@juanibiapina Yes, the compinit will also be removed. Sorry for the disruption.

@jthegedus yes, assuming no breaking changes have been merged since 0.7.7 was tagged. I don't think there were any, but as soon as you merge this I'll check and then tag 0.7.8.

I think we are good to go now. Updates to plugins can hopefully be socialised by those who use them once they find this "feature" was reversed.

@Stratus3D Please cut a new release when you have the time, cheers 🍻

0.7.8 has been tagged. 🎉