AlecAivazis / survey

A golang library for building interactive and accessible prompts with full support for windows and posix terminals.
MIT License
4.08k stars 350 forks source link

Help is not rendered for Multiline input #236

Open patrickdillon opened 5 years ago

patrickdillon commented 5 years ago

The help message is not visible for multiline inputs. I create it like this:

err := survey.Ask([]*survey.Question{
        {
            Prompt: &survey.Multiline{
                Message: "Service Account",
                Help:    "The location to file that contains the service account in JSON, or the service account in JSON format",
            },
        },
    }, &content)

but the output looks like this: ? Service Account [Enter 2 empty lines to finish]

MarkusFreitag commented 5 years ago

The help handling is missing in Multiline.Prompt. @AlecAivazis What do you think is the best way to implement that? Should the help message be displayed when the user types the help char followed by one newline? I think it's a bit tricky for this component.

AlecAivazis commented 5 years ago

Hmm this is a tricky one. I"m really not sure what the right solution is.

The only alternative to what you described @MarkusFreitag is something like what vi does with :. We could go into a special mode if the user presses esc but I would prefer not to rely on esc since I think that's an intuitive solution to skipping a prompt...

@coryb any ideas?

coryb commented 5 years ago

For Input we tell the user to enter an isolated ? as the answer to get help, it is probably reasonable to follow the same logic for Multiline, so something like:

?
<return>
<return>
coryb commented 5 years ago

We could add some specialized vi escape codes, but I would expect this to be incoherent to many tool users that are not also vi people. We could also try some ctrl-? type magic code, but if we did that we should probably make it consistent for many prompts that have help prompts.

AlecAivazis commented 5 years ago

If we go with the first, we force the user to go back up and delete the lines they just created. If memory serves, the multiline input does not support up/down arrow keys very well (I forget the specific details). Given how hard we've tried to keep the API consistent, I am apprehensive about implementing any one solution unless it is a clear winner. I think we're going to have to sit on t his for awhile until we figure out a better interaction.

I know that's not the answer you wanted to hear @patrickdillon but maybe you can try implementing ^ and testing it with your users to see what they think? If we could collect feedback from people actually using the prompts, it would go a long way to create confidence in a solution.