Auto completion for partial arguments

[alankm]

I'm trying to get bash auto completion working for my string arguments based on hints that I'm correctly defining in my app.

"myapp --completion-bash" is correctly returning a list of custom hints I've specified for the argument.

But "myapp a --completion-bash" does not return a subset of the previous list based on which ones match the prefix 'a'. This means that bash won't use tab to auto complete the argument.

Is there a way to achieve the desired behaviour?

[alecthomas]

Sorry this took so long. Do you have a test case that can replicate this?

[alankm]

Certainly, here's an example:

package main

import "github.com/alecthomas/kingpin"

var (
	arg   = kingpin.Arg("arg", "").HintOptions("alpha", "bravo", "charlie")
	input = arg.String()
)

func main() {

	kingpin.Parse()

}

If you run "go run main.go --completion-bash" it helpfully returns the list of hint options, but if you've already half typed one of the options, like "go run main.go alp --completion-bash" it can't auto-complete the remainder of your argument.

I don't think this is a bug. Your documentation only states that auto-completion works for commands/subcommands and flags, but never makes any promises about arguments. I don't know if this is by design -- I can imagine a few reasons that this would be difficult to implement -- but it would definitely be very nice.

This argument autocompletion does work in the bash for existing file or directory arguments, but I think that's behaviour programmed into bash and not kingpin.

Thanks!

[alecthomas]

This is occurring due to several factors:

1. The partial text is a valid match for that argument. This means that argument has been accepted and the next element's hints are being used.
2. Kingpin does not have a cursor location, so we can't differentiate between alp<tab> and alp <tab>. This would disambiguate this case.

If the latter were possible, I think this could be solved, but without that information I don't think it can be fixed. Any thoughts?

[alecthomas]

This ambiguity does not exist for commands or flags, because they either "match" or "do not match".

[alankm]

I can see what you mean. I presume that the arguments to your script are default bash behaviour, meaning that we can't adjust it to include that distinction between alp<tab> and alp <tab>?

I think there surely must be a solution, because it felt like a missing feature when I encountered it, so I imagine that I've seen it working somewhere before. Unfortunately I cannot think what the answer is.

Is there a way to define values that should not be accepted? Kind of like the opposite of a ".HintOptions" function. Instead of telling Kingpin what values to suggest, provide a function or filter kingpin should call to check the argument and see if it works?

Perhaps the functionality could be integrated seamlessly by calling the PreAction for each element during the autocompletion. PreAction could validate arguments and return an error if it fails, and if it fails then the autocompletion logic would know that the argument has not been accepted and can therefore continue trying to match using the current value as a prefix?

[alecthomas]

Turns out that this should actually be possible (from a shell perspective). $COMP_CWORD is the current word being completed. Unfortunately, that context is lost to Kingpin due to the way arguments are passed into it from the completion function. Changing this would be a fair bit of work.

[alankm]

Ah. Well, that's all I can contribute I'm afraid. I hope the feature finds its way in someday. I do think it would be a fantastic quality-of-life improvement.