Unable to get completion to work in ~/.zshrc

[JCzz]

Thanks great tool!

Beneath is a simple command, but I am unable to get completion to work in ~/.zshrc.
Should the following steps not work:

1. fpath+=$PWD
2. go build -o auto main.go
3. source <(./auto completion zsh)
4. Or: ./auto completion zsh > "${fpath[8]}/_auto"

"Error": <TAB> <TAB> only shows the files in the folder?

Note: I have added this autoload -U compinit; compinit to ~/.zshrc and opened a new terminal, before running the above steps.

And eventually when it works, I should add fpath+=<only path to the folder containing _auto> from executing ./auto > "${fpath[<index of the added url>]}/_auto to ~/.zshrc right?

Any help appreciated, thanks

package main

import (
	"fmt"
	"github.com/spf13/cobra"
	"os"
)

var RootCmd = &cobra.Command{
	Use: "say",
	Long: "Root command",
}

var HelloCmd = &cobra.Command{
	Use: "hello",
	Short: "Say hello",
	Run: func(cmd *cobra.Command, args []string) {
		fmt.Println("Hello!!!")
	},
}

var ByeCmd = &cobra.Command{
	Use: "bye",
	Short: "Say goodbye",
	Run: func(cmd *cobra.Command, args []string) {
		fmt.Println("Bye!!!")
	},
}

func init() {
	RootCmd.AddCommand(HelloCmd,ByeCmd)
}

func main() {
	if err := RootCmd.Execute(); err != nil {
		fmt.Fprintln(os.Stderr, err)
		os.Exit(1)
	}
}

[marckhouzam]

Hi @JCzz.

source <(./auto completion zsh) is not supported by Cobra because it is not the approach recommended by zsh. To use source you need to also do compdef _auto auto.

However adding _auto to fpath should work. It may be that you need to start a new shell after having added that file.

[JCzz]

Thanks @marckhouzam I did add _auto to fpath in step 4, but it does not work.

Do you know if it should work with the following plugins:

# Oh My Zsh
  plugins=(
    kubectl
    colored-man-pages
    zsh-syntax-highlighting
    zsh-autosuggestions
  )

Should fpath also be set in ~/.zshrc, I am doing this on every test:

go build -o auto main.go
./auto completion zsh > _auto
fpath+=$PWD/_auto

In ~/.zshrc I have:
eexport PATH=<folder path>/auto:$PATH

Also looked at #1534 but still the same problem

[github-actions]

This issue is being marked as stale due to a long period of inactivity

[sirianni]

source <(./auto completion zsh) is a much friendlier approach because it does not require a file to be manually managed in fpath. When the CLI is upgraded the new completions will be picked up the next time the shell is opened, rather than having to manually update the file.

Note that both kubectl and helm recommend that approach. You can see here how kubectl is working around the cobra issue by manually prepending the compdef to the Cobra output. It looks like @marckhouzam himself made that PR!

[marckhouzam]

source <(./auto completion zsh) is a much friendlier approach because it does not require a file to be manually managed in fpath. When the CLI is upgraded the new completions will be picked up the next time the shell is opened, rather than having to manually update the file.

This was originally my opinion also, but then I realized I was basing it on my own usage habit.
A normal user will install a tool through a package manager and that installation will setup shell completion automatically.
On upgrade, the package manager will take care of things automatically.

I believe zsh recommends using _fpath as it speeds up shell startup by avoiding having to source all your different completion scripts for each new shell instance. Based on this, the Cobra maintainers decided to follow the recommended practice.

But as you mention below, this can be overridden by the program.

Note that both kubectl and helm recommend that approach. You can see here how kubectl is working around the cobra issue by manually prepending the compdef to the Cobra output. It looks like @marckhouzam himself made that PR!

This was for backwards-compatibility, where I didn't want to break the existing method used by kubectl.

[sirianni]

Thank you for the quick and thoughtful response! Perhaps we could add an option to make this work in Cobra?

One of the benefits of golang is that you can create a single CLI binary that doesn't necessarily warrant installation via a package manager. My company develops a CLI that is installed via direct download and while we could work around this the same way kubectl does it would be great to have first-class support for this in Cobra.

[marckhouzam]

/cc @jharshman

[saheljalal]

After upgrading to the latest cobra version, I'm running into the same issue where completions were broken in my tool. I tried to rework it to use the fpath method as described but unfortunately zsh just doesn't see or register the completions afaict.

Using the workaround in kubectl does fix my problem though.

Noticed the mention of zsh-syntax-highlighting as well which I use but moved to the bottom of my .zshrc and still no luck. Not sure if the documentation needs updating with step by step info but getting completions to work in zsh appears to be really complicated as of now unfortunately for me.

[jharshman]

Not sure why this would have broken in the lastest version.
@sirianni, @marckhouzam is correct, zsh sourcing from fpath is recommended in order to speed up shell startup.
Are you suggesting we support both methods?

[sirianni]

Not sure why this would have broken in the lastest version.

I don't think this has anything to do with the version.

zsh sourcing from fpath is recommended in order to speed up shell startup. Are you suggesting we support both methods?

Yes, that's what I'm suggesting. With due respect to the ZSH developers, I think users should be permitted to make their own decisions with regards to how their zsh environment is configured. I personally value the superior ergonomics of the source <(./auto completion zsh) over the minscule improvement in shell startup time using fpath. I start up new shells maybe every few hours - I don't care about a few extra milliseconds to get the completion from running an binary vs. sourcing a static file.

The "package manager will take care of this for you" argument is somewhat compelling, but one of the reasons people use golang is to have single binaries that can easily be distributed without a package manager. This is exactly what my company is doing. In the end, I don't see much downside of giving library users a choice.