---

It provides several different prompts in order to interactively ask the user for information via the CLI. With inquire, you can use:

• Text to get text input from the user, with built-in autocompletion support;
• Editor* to get longer text inputs by opening a text editor for the user;
• DateSelect* to get a date input from the user, selected via an interactive calendar;
• Select to ask the user to select one option from a given list;
• MultiSelect to ask the user to select an arbitrary number of options from a given list;
• Confirm for simple yes/no confirmation prompts;
• CustomType for text prompts that you would like to parse to a custom type, such as numbers or UUIDs;
• Password for secretive text prompts.

---

Demo

Source

Features

• Cross-platform, supporting UNIX and Windows terminals (thanks to crossterm);
• Several kinds of prompts to suit your needs;
• Standardized error handling (thanks to thiserror);
• You can choose your terminal backend between crossterm (default), termion or console.
  • Perfect if you already use one library and do not want additional dependencies.
• Support for fine-grained configuration for each prompt type, allowing you to customize:
  • Rendering configuration (aka color theme + other components);
  • Default values;
  • Placeholders;
  • Input validators and formatters;
  • Help messages;
  • Autocompletion for Text prompts;
  • Confirmation messages for Password prompts;
  • Custom list filters for Select and MultiSelect prompts;
  • Custom parsers for Confirm and CustomType prompts;
  • Custom extensions for files created by Editor prompts;
  • and many others!

Examples

Examples can be found in the examples directory. Run them to see basic behavior:

cargo run --example expense_tracker -p inquire-examples

Usage

Put this line in your Cargo.toml, under [dependencies].

inquire = "0.9.4"

* This prompt type is gated under a feature flag, e.g.:

inquire = { version = "0.9.4", features = ["date"] }

Cross-cutting concerns

There are several features that are shared among different types of prompts. This section will give an overview on each of them.

Rendering configuration (aka color themes)

All prompts allow you to set a custom RenderConfig, a struct that contains lots of style customization options.

With RenderConfig, you can customize foreground color, background color and attributes (e.g. bold) of most components that are part of a prompt. Additionally, you can also customize the content of special tokens, such as prompt prefixes, highlighted-option prefixes, selected and unselected checkboxes, etc. If you do not want to re-set the render config object for each new prompt you create, you can call inquire::set_global_render_config to set a global RenderConfig object to be used as the default one for all future prompts.

This allows you to have greater control over the style of your application while continuing to have a clean API to create prompts as smoothly as possible.

In the render_config.rs example, you can take a look at the capabilities of this API. The example is exactly the same one as expense_tracker.rs, but with several style aspects customized. Take a look at their differences:

Source Source

Validation

Almost all prompts provide an API to set custom validators.

The validators provided to a given prompt are called whenever the user submits their input. These validators vary by prompt type, receiving different types of variables as arguments, such as &str, &[ListOption], or NaiveDate, but their return type are always the same: Result<Validation, CustomUserError>.

The Validation type is an enum that indicates whether the user input is valid, in which you should return Ok(Validation::Invalid), or invalid, where you should return Ok(Validation::Invalid(ErrorMessage)). The ErrorMessage type is another enum, containing the Default and Custom(String) variants, indicating the message to indicate the user that their input is invalid.

With an Invalid result, it is recommended that you set the ErrorMessage field to a custom message containing helpful feedback to the user, e.g. "This field should contain at least 5 characters".

This is the beginning of the README. Read the rest at the original. Read the full README ↗