Completion question

[fonimus]

trafficstars

Hello, I have a question about options completion : should complete give options when we auto complete another option ?

Here is an example, with color option an enum with EnumValueProvider :

complete::>help echo
NAME
       echo - Echo command

SYNOPSIS
       echo [--message String] --color PromptColor

OPTIONS
       --message String
       [Mandatory]

       --color PromptColor
       [Optional]
       

complete::>echo --color 
--message   BLUE        CYAN        MAGENTA     WHITE
BLACK       BRIGHT      GREEN       RED         YELLOW

The question here is : should --message be here with completion proposals of color option ?

Thanks a lot !

[jvalkeal]

Ah yeah answer is yes and no. I think we need to make completion a bit better what comes for a combination of a argument types in a context of a completion. We can try to see how clever we're able to make it as --message could be a boolean which doesn't need arguments(thought this case it's string and possibly requiring an value).

Completion probably needs to be more aware of a parsing context but it gets more complex.

[fonimus]

I did not think of boolean option, so we could complete with options only if previous option is NOT boolean. But of course completion would become more complex 😄

[jvalkeal]

Completion is indeed a bit different when you have a full context in your disposal vs. like generating bash(we have naive impl for that). In interactive shell this is something we should support. It's going to be iterative development as there's so many different use cases, etc.

[dmarthaler]

Hello, I have a question about options completion : should complete give options when we auto complete another option ?

Here is an example, with color option an enum with EnumValueProvider :

complete::>help echo
NAME
       echo - Echo command

SYNOPSIS
       echo [--message String] --color PromptColor

OPTIONS
       --message String
       [Mandatory]

       --color PromptColor
       [Optional]
       

complete::>echo --color 
--message   BLUE        CYAN        MAGENTA     WHITE
BLACK       BRIGHT      GREEN       RED         YELLOW

The question here is : should --message be here with completion proposals of color option ?

Thanks a lot !

I just updated from 2.1.0.M3 to 2.1.2 and changed my custom ValueProvider implementations so that it reflects the changed interface. After complementing my @ShellOption annotations using the valueProvider attribute I found this behavior of interactive completion that command option completion is mixed with values provided from my own implementation

1. Is this behavior desired?
2. If yes, how can I influence it?

Before the "Interactive mode completion went through a rework" in 2.1.0-RC1 it behaved differently (using 2.1.0.M3):

[kohlmu-pivotal]

@jvalkeal I have the same problem. I have registered a Command with the CommandRegistration.Builder. The CommandOption has a CompletionResolver which specifies a collection of options. When using <TAB> the completion provides me all the values from the CompletionResolver in addition to all the CommandOptions for the command that I have not yet used. This makes it a little hard to find all the values that one would like to use.

Could one not have some logic that determines that if a CompletionResolver is provided, that the completion only shows those values until at least 1 of the values has been selected?

On could possibly make this logic better, by including extra logic that recognizes a ',' to indicated multiple values, but as soon as at least one value out of the CompletionResolver has been provided, the completion logic can continue showing all the other options that start with --