bug: Regression in Zsh Completion for asdf Java set Command (v0.16.6 & v0.16.7)

[michelemadonna]

Describe the Bug

I have identified a regression in asdf versions 0.16.6 and 0.16.7 that affects the Zsh completion functionality. Specifically, when using the set command to configure the current Java JDK version, the completion system incorrectly suggests all installable JDK versions instead of only listing the currently installed JDK versions.

This issue was not present in asdf version 0.16.5, where the command completion correctly displayed only the JDK versions installed on the system.

Steps to Reproduce

1. Install asdf v0.16.6 or v0.16.7.
2. Use Zsh as your shell.
3. Run the following command and attempt auto-completion:
4. asdf set java
5. Observe that the completion suggests all available JDKs (installable), rather than only the installed ones.

6. Downgrade to asdf v0.16.5.
7. Run the same command again.
8. Observe that the correct behavior is restored, showing only installed JDK versions.

Expected Behaviour

When using the set command in Zsh completion, only the JDK versions installed on the system should be suggested.

Actual Behaviour

When using the set command in Zsh completion, in versions 0.16.6 and 0.16.7, the completion instead lists all installable JDK versions.

Environment

Macos 15.3.2
zsh 5.9 (x86_64-apple-darwin24.0)
Homebrew 4.4.27-3-gfaddb73

asdf plugins affected (if relevant)

java

[Stratus3D]

@michelemadonna asdf set can be used to set any version of a tool. Setting a tool to a valid version that isn't installed is a pretty common pattern. Define all the tool versions you want to use for a project, then run asdf install to get everything installed.

I guess the question is here, do we want to suggest uninstalled versions differently than installed versions? It's understandable that some users may want to choose from a list of already installed versions.

[mhagnumdw]

I guess the question is here, do we want to suggest uninstalled versions differently than installed versions? It's understandable that some users may want to choose from a list of already installed versions.

Yes, that would be a good thing.

[michelemadonna]

@Stratus3D

I guess the question is here, do we want to suggest uninstalled versions differently than installed versions? It's understandable that some users may want to choose from a list of already installed versions.

The previous implementation was designed as an efficient way to switch between already installed versions of a tool on the system. This was particularly useful for users who wanted a quick way to work with available versions without dealing with uninstalled ones.

Additionally, the asdf set command does not currently install any uninstalled versions of the selected tool. This reinforces its role as a simple switch for existing installations rather than a mechanism for defining and fetching versions not yet present.

While suggesting uninstalled versions might be beneficial in some cases, it's important to consider that many users expect to select only from what's already installed.

[michelemadonna]

I'm not a Zsh expert, but I tried this fix to restore proper completion functionality for the set command using the existing _asdf__installed_versions_of_plus_system function, and it seems to work:

(set)
    # Handle set command completion
    case $CURRENT in
      3)
        _alternative \
          'flags:flags:((-u\:"set version in user home directory" -p\:"set version in closest parent .tool-versions"))' \
          'plugin:plugin:_asdf__installed_plugins'
        ;;
      4)
        if [[ ${words[3]} == -* ]]; then
          # After flag, complete with plugin name
          _asdf__installed_plugins
        else
          # Complete with available versions for the plugin
          #local versions
          #if versions=$(asdf list all "${words[3]}" 2>/dev/null); then
          #  _wanted "versions-${words[3]}" \
          #    expl "Available versions of ${words[3]}" \
          #    compadd -- ${(f)versions}
          #fi
          _asdf__installed_versions_of_plus_system ${words[3]}  # <-- 🆕 Use the existing function to get versions
        fi
        ;;
      *)
        # Support for multiple version specifications
        if [[ ${words[3]} == -* ]]; then
          local plugin="${words[4]}"
        else
          local plugin="${words[3]}"
        fi
        #local versions
        #if versions=$(asdf list all "$plugin" 2>/dev/null); then
        #  _wanted "versions-$plugin" \
        #    expl "Available versions of $plugin" \
        #    compadd -- ${(f)versions}
        #fi
        _asdf__installed_versions_of_plus_system "$plugin"  # <-- 🆕 Use the existing function to get versions
        ;;
    esac
    ;;

on MacOs 15.5 Sequoia with Brew

also tested on Ubuntu 24.04 LTS

[michelemadonna]

@mhagnumdw

Yes, that would be a good thing.

I don't think it's a matter of deciding whether or not it would be appropriate to find a way to indicate the versions present on the system, but simply a matter of aligning the behavior of autocompletion in zsh with that of the set command in bash, which hasn't been modified in any way compared to previous versions.