Would it be possible to implement this scheme? A hard-coded match statement feels quite limiting. It could easily turn into a "kitchen sink", with users continually requesting more commands to be added.

For what it's worth, I'm on macOS and don't use tools like pacman or pass, so having them in the default list feels a bit off. I imagine this concern will only grow as more items get added over time.

You're right, the hard-coded match is not ideal. I investigated a dynamic dispatch approach that works within Nushell's constraints.

Users could define an $env.FZF_COMPLETERS record in their config.nu with closures keyed by command name. Each closure receives the prefix and returns a list of candidates, which are then fed to fzf:

# In config.nu
$env.FZF_COMPLETERS = {
    git: {|prefix| ["branch-main", "branch-dev", "branch-feature"]}
    pacman: {|prefix| ^pacman -Slq | lines}
}

In completion.nu, we'd check $env.FZF_COMPLETERS before falling through to the built-in defaults:

let user_completers = ($env.FZF_COMPLETERS? | default {})
if ($cmd_word in $user_completers) {
    # call _fzf_complete_nu with the user's closure
} else {
    match $cmd_word {
        "ssh" | ... => { ... }
        "kill"      => { ... }
        ...
    }
}

I tested this end-to-end: defining a completer in config.nu, triggering git **<TAB>, selecting from fzf, and confirming the result is inserted on the command line. It works.

With this in place, we could remove pacman, paru, and pass from the default match and keep only the universal ones (ssh, kill). The question is where to provide the removed implementations as examples for users -- perhaps in the README or in a separate example file. What do you think?

Limitation: The closures must be defined in config.nu, not in a separate autoload file, because Nushell doesn't propagate $env mutations from autoload files to later-loaded files. This is consistent with how users configure other Nushell settings.

With this in place, we could remove pacman, paru, and pass from the default match and keep only the universal ones (ssh, kill). The question is where to provide the removed implementations as examples for users -- perhaps in the README or in a separate example file. What do you think?

Sounds good to me. How about putting them under shell/completion-examples.nu (any better name suggestion?) and add a link to the file in the README file?