A quick solution might be the following, since a good solution requires a complex remodeling process, but it is so dirty that I dare not open a PR

pub fn prompt_skippable(self) -> InquireResult<Option<T> {
        if self.help_message == DEFAULT_HELP_MESSAGE {
            self.help_message = Some(DEFAULT_HELP_MESSAGE.unwrap() + ", ESC to select none")
        }
        match self.prompt() {
            Ok(response) => Ok(Some(response)),
            Err(InquireError::OperationCanceled) => Ok(None),
            Err(err) => Err(err),
        }
        if self.help_message == DEFAULT_HELP_MESSAGE {
            self.help_message = DEFAULT_HELP_MESSAGE
        }
    }

It's probably going to be a breaking change, but I think it'll lead to a better design for the long-term anyway. What do you think of changing Prompt::help_message from Option<String> to HelpMessage which can be one of 3 variants: None, Default, Custom(String)?

I had a look at your PR and I do believe that a new enum HelpMessage could provide better default help messages suitable for customizations of each prompt.
However, I think there is still some work to do to be able to have different help messages in the case of prompt_skippable, since there is no parameterization of the help message and then prompt and prompt_skippable have the same message.

Let me know if I can help in any way

However, I think there is still some work to do to be able to have different help messages in the case of prompt_skippable, since there is no parameterization of the help message and then prompt and the prompt_skippable have the same message.

Yeah I see what you mean, it was at that point I decided to call it a day lol, will work more on it tonight

So @dariocurr here's what I'm thinking, it's going to be an actual brain dump here so don't expect a coherent stance, just me thinking out loud and see what your opinions are.

Firstly, there is no change in behaviour when the prompt is or isn't skippable.

On both cases, the esc key leads to leaving the prompt. The prompt_skippable method is something created for the convenience of transforming a cancelled prompt into an empty response, but it isn't really a happy path for the prompt.

I was thinking a bit more on each of the prompts, on what needs to be done for a happy path to allow "optional input":

• CustomType:
  • Call prompt_skippable() and the user can leave with esc
  • Make T an Option, make the parser parse an empty input into a None. There are other ways involving newtypes too. The benefit of this one is that the user doesn't need to know the esc, they can jump the prompt by pressing enter on an empty input.
• Confirm: this prompt precedes an action by nature, and so the result is used to decide to do or not do something based on the true/false result. If a None is wanted, probably just a default pre-configured in the prompt is what's really needed.
• MultiSelect: no options selected are already part of the usual flow.
• Text: empty inputs are also normally allowed.
• Password: empty inputs are also normally allowed.
• Editor: same thing
• Select is the edge-case, and not coincidentally the one you brought up. Selections are required by default.

The thing is that there can be two semantical constructs here: 1. actively skipping a prompt; 2. giving an empty-like response.

It seems you're trying to achieve 2 (based on the error message you suggested), in that you want Select, but the user can pick 0-1 answers.

prompt_skippable is basically a hack I did and thinking back not a very good UX. It leads to an inconsistent user story where it makes the normal prompt() implicitly not skippable, and as such "required". But as I said we allow Text, Password, Editor to receive empty inputs by default. What I'm trying to say is that the "what is skipping" and "what is a legit empty input" stories are mixed.

Maybe what we do want is to allow Select to receive an empty answer, kind of allow_no_selection(), and then idk, create a new shortcut? Display a symbolic (skip) option? We can think more about what a solution on that front would look like later.

What prompted all of these thoughts is that, when thinking of the new error message, I had ESC to skip in my mind, and not ESC to select none, and that led to this whole chain of which is which.

Concluding here, I don't have a conclusion, and not even a preference for now tbh. I want to find a good, long-term, design that's actually well-planned as the next inquire's release will be v1.0. And for that I'm willing to take some liberty in new design and architectural changes.

cc @IniterWorker you might be interested in the skip vs empty input discussion