mikaelmello / inquire Goto Github PK

Describe the bug

Strings rendered by the backend that contain new-line characters (\n) are not properly handled. Creating two problems:

1. In raw_mode, new line characters just move the cursor down one row. We need to manually inject \r to these strings.
2. The prompt-cleaning algorithm, the one that resets all rows currently written, does not account for the additional number of lines created by these strings. We need to check them too.

To Reproduce

    let ans = Confirm::new("Do you live in\nBrazil?")
        .with_default(false)
        .with_help_message("Don't worry!\nBe happy!")
        .prompt()
        .unwrap();

    println!("Your answer: {}", ans);

    let ans = Confirm::new("Do you live in\nBrazil?")
        .with_default(false)
        .with_help_message("Don't worry!\nBe happy!")
        .prompt()
        .unwrap();

    println!("Your answer: {}", ans);

Expected behavior

[mikael@mello inquire]$ cargo run --example multi_line_help_message 
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/examples/multi_line_help_message`
? Do you live in
Brazil? No
Your answer: false
? Do you live in
Brazil? Yes
Your answer: true

Screenshots

Is your feature request related to a problem? Please describe.
When the user inputs data, the default prompt shown begins with a light-green question mark. When the input completes, that question mark remains.

Describe the solution you'd like
I would love for the question mark to become a check mark or so.

Additional context
Thank you for this library. I really like the prompts I’m able to create with it!

Example (using Dialoguer)

Describe the bug

I saw it happening once, I don't remember exactly the IO error code, but it wasn't properly catched by the terminal constructor. Investigate better if I got it right with the current solution

Is your feature request related to a problem? Please describe.

The selected date cursor in date prompts is entirely artificial, we explicitly add a background and foreground colors on where the cursor should be. Meanwhile, the actual cursor is hidden at the end of the prompt.

Ideally, we should position the cursor where it should actually reside. I'm not sure if this helps with accessibility, it would be even more worth it if it does.

We probably will continue to hide the cursor, as we can't highlight an entire 2-digit date with a cursor of width 1. But just having the cursor there is important.

Describe the solution you'd like

The backend should mark where the cursor should be and move it to the correct place after rendering the entire prompt.

Is your feature request related to a problem? Please describe.

The user might not want to manually navigate through several days/months/years when trying to input a date. Imagine a birthday for example.

We have shortcuts in place for this, in which ctrl+arrows quickly move by months or years, but it could be better

Describe the solution you'd like

Not sure yet...

Option 0

A new prompt type where instead of a calendar, we display the three date parts (month, date, year) in a customizable order with customizable separators.

The end user can then move around each one of them pressing left or right arrows, and then press up or down to update the values.

Option 1

The user can type a full date in a predefined format, e.g. dd/mm/yyyy and submit. The prompt handler should then try to parse this input and if successful, return the parsed value.

The submit button could be a new shortcut, e.g. Ctrl+Enter, or the same Enter.

Maybe we could do the following:

• Space for selecting on interactive calendar
• Enter to submit current input, or current calendar selection if input is empty.

It would be nice if the expected input format was written in grey where the input would be, something like:

? Travel date: 12/0m/yyyy

Option 2

I tried to think of a "filter" approach, like typing a month or year and then the calendar would jump right on that, but didn't get to a reasonable solution.

Not sure if useful, but it would be fun

great 🌍, 🍞, 🚗, 1231321📞, 🎉, ♥️, 🍆xsa232 s2da ake iak eaik

When pasting this input on any prompt that uses the Input struct for interactive cursors, moving around the string gets all weird because of the one heart character.

Understand why this is happening and how to fix it.

Is your feature request related to a problem? Please describe.

I'm trying to create a validator that uses user provided Regex patterns against the input. These patterns come from a settings file, and I'd like to be able to pass the validator around. With the current API of StringValidator, it is possible but very hacky and verbose as it must be turned into a lambda to work.

It would be great to instead be able to use structs that implement a trait. These could then be easier passed around.

Describe the solution you'd like

The validators being a trait like the following for the StringValidator:

trait StringValidator {
    fn validate(&self, value: &str) -> Result<(), String>
}

Then it can be implemented for all lambdas, to preserve the previous API:

impl<F> StringValidator for F
where
    F: Fn(&str) -> Result<(), String>,
{
    fn validate(&self, value: &str) -> Result<(), String> {
        (self)(value)
    }
}

But in addition, we can have structs with addition state, as well:

struct RegexValidator(Regex);

impl StringValidator for RegexValidator {
    fn validate(&self, value: &str) -> Result<(), String> {
        match self.0.is_match(value) {
            true => Ok(()),
            false => Err(format!("value must match pattern `{}`", self.0)),
        }
    }
}

This is currently still possible with lambdas, but especially when using shared values, it is very difficult to implement. Often forced to put this the same function where it is called.

Is your feature request related to a problem? Please describe.

We should allow library users to disable colors in the output, keeping it simple.

Describe the solution you'd like

We should allow colors to be disabled on a prompt-by-prompt basis, that's for sure. But it would also be great to expose an API to change some sort of global settings in the library, which would also be really useful for #6.

Is your feature request related to a problem? Please describe.

The cursor in text prompts is entirely artificial, we explicitly add a background and foreground colors on where the cursor should be. Meanwhile, the actual cursor is hidden at the end of the prompt.

Ideally, we should position the cursor where it should actually reside. I'm not sure if this helps with accessibility, it would be even more worth it if it does.

Describe the solution you'd like

The backend should mark where the cursor should be and move it to the correct place after rendering the entire prompt.

Is your feature request related to a problem? Please describe.
I have a list of options where some are different types and it would be good to make them visually distinctive in the prompt.

For my case, I'd like to be able to highlight the option that is currently in use so that users can see they're not going to change anything.

Describe the solution you'd like
A new field+method on the Select prompt to add an option_formatter of type (something like) &'a dyn Fn(ListOption<&T>) -> Styled that would let the appearance of options be determined at run time.

Describe alternatives you've considered
I initially thought this is what the existing formatter field was used for but that seems to only be used to render the selected option.
I also tried wrapping my T in a new type and adding ansi formatting in its Display impl. This seemed to be cleared somewhere in the rendering.

Additional context
I'm not sure how this would interact with the RenderConfig and keeping the presentation consistent across multiple prompts.

It could also be interesting to have access to the selected/highlighted state of the option so that options can be presented differently when they're highlighted (eg to display additional help). Something like

> one (more info on one)                           one
  two                      >>>scroll down>>>     > two (more info on two)
  three                                            three

Is your feature request related to a problem? Please describe.

Faster navigation might be very helpful to some users, specially in long lists.

Unfortunately, other hotkeys such as arrows are already taken by input parameters.

Describe the solution you'd like

When the user presses Page Down or Page Up, navigation will jump to the next page, with no options in common with the current page.

Exception: page up and page down should never wrap around the list, stopping at the first or last items, respectively.

Question: should we also disable page wrapping on arrow up and arrow down keys? As we would have fast ways (the page keys) to go to the end of the list.

Is your feature request related to a problem? Please describe.

Generating each recording is a boring process with a lot of manual changes required. The recordings are even a bit outdated on functionality just because I didn't want to re-record everything which would require a lot of time.

Describe the solution you'd like

Have a set of recordings each containing the example to run and a series of keystrokes to perform.

Then automatically run these examples with the provided keystrokes, recording the terminal output and generating .cast and .gif outputs.

Describe alternatives you've considered

I thought of recording the keystrokes to give it a more natural feel but sometimes that's worse. For example when the recorder (I) take too long for the next action or type too fast worsening UX. Executing the keystrokes at a constant interval seems good enough.

Is your feature request related to a problem? Please describe.

In order to improve the developer's experience and reduce the need for repetitive code, it would be great to have an API to set global configuration parameters applied to all prompts created from that moment in time.

Describe the solution you'd like

See Additional context

Additionally, extend this from just render configs, storing defaults for things such as page size, vim mode, help messages, terminal impl (although this one is not publicly settable), etc.

Finally, consider whether to allow or not multiple updates in global configs.

Additional context

Before

    let render_config = get_render_config();

    let _date = DateSelect::new("Date:")
        .with_render_config(&render_config)
        .prompt()?;

    let _category = Select::new("Category:", get_categories())
        .with_render_config(&render_config)
        .prompt()?;

After

    let render_config = get_render_config();
    inquire::set_default_render_config(render_config);

    let _date = DateSelect::new("Date:").prompt()?;

    let _category = Select::new("Category:", get_categories()).prompt()?;

Describe the bug
I can't manage to make autocomplete work with a Text prompter. Thinking it was my code, I cloned the repo and ran the expense_tracker example, but the autocomplete didn't work either.

Unlike in the demo, I didn't get any autocomplete when hitting the tab key with the payee field. Has it been broken or am I not using it correctly?

Thanks

To Reproduce
Steps to reproduce the behavior:

1. git clone https://github.com/mikaelmello/inquire
2. cd inquire && cargo run --example expense_tracker --features="builtin_validators date"
3. Try to complete the payee field (third field) with the tab key as shown in the demo
4. Autocomplete doesn't work

Expected behavior
Complete the input.

Desktop (please complete the following information):

$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="20.04.3 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.3 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

Is your feature request related to a problem? Please describe.

This is important for me when I stay away the project for a little while (like last month) and have to remember all of the steps, even though there aren't that many.

Describe the solution you'd like

An update CONTRIBUTING.md (or another file) that describes the release process in detail.

Is your feature request related to a problem? Please describe.
A bit crazy idea but it may result in something useful in another way. A calendar is a convenient and easy to use widget. But sometimes it is good to see extra information. E.g, if I choose a day for a new appointment, I'd like to know what days are already booked. A good example is Google Calendar that highlights today and all dates which I have already filled with another appointment. Yes, terminal has fewer ways to mark a date, but we can use colors/background colors/boldness/underline/italic.

Describe the solution you'd like
I see two ways to do it:

• Allow a user to pass a list of dates to highlight. A sufficient solution when one type of highlight is enough. But the solutions turns bad when a user has a long list of dates (think of passing all the dates for at least the current year).
• Add a callback to calendar display function. The callback argument is a date(maybe more but the date is required). It returns(as Option: None means display with default colors) foreground, background colors, and maybe style(bold/underline/etc). A flexible way but requires more work from a user.

Describe alternatives you've considered
I did not consider no alternatives.

Additional context
It is an example of GUI calendar (grey = today, red = have something).

New version of the text, for previous ones just check the edit history

Hi everyone!

The development of this project has become a bit slower-paced for a few months now. The reason for this is that it has reached a stage where I, personally, am satisfied with the current set of features, covering the scope I envisioned for this project.

Of course, this isn't to say that the project is done or there aren't improvements to be made, but that anything new is likely coming from your needs and wants.

So, this text is just me confirming that this project still has my full attention.

If you have any issues when using it, or features you need, let us know and we can work together to find a solution :)

Describe the bug
If the error message is longer than the available terminal width, the error messages start to appear one below the other when any key is pressed.

To Reproduce
Steps to reproduce the behavior:

1. Add long message to validator
2. Set terminal window less then validation message length
3. Get validation error
4. Press left arrow key or backspace or continue typing

Expected behavior
The error message keeps its position on the screen.

Screenshots

Desktop

• OS: ArchLinux
• Version: Latest

Additional context
Can be related to #15

Is your feature request related to a problem? Please describe.

For a long select and multiselect. It may be helpful to indicate the position of an item in the list (for example, 6 out of 123).

Describe the solution you'd like

This should not be enabled by default, the user should have to explicitly set it, like this:

let option = Select::new("Prompt", &options)
    .with_indicators(true)
    .prompt()?;

Additional context

Should original indexes be kept on a filtered list, or should indexes relative to the filtered list be displayed?

for stuff like "order in which I will watch movies this summer"

Currently, the pre-built validators via macros do not have any type annotations so they can be used freely whether the validators come from str arguments or Vec.

The length validators use the simple len() method to get the length of the answer. On strings, this can fail with unicode characters, as the len method returns the number of bytes IIRC and we should count the graphemes, with something like that: ans[..].graphemes(true).count()

Figure out a way to fix this while maintaining the following API:

• The user should be able to call a macro or simple method or create a simple object: length!() ; length() ; Length::new().
• This single API should automagically handle all the different validators that are applicable.

Is your feature request related to a problem? Please describe.

When checking out some projects that use inquire, I noticed that two of them are using Select/MultiSelect prompts to allow the user to select enum variants, such as an enum for currency or maybe settings.

Each one had their own way to make it work and I thought it would be a great idea to incorporate this into the lib.

Describe the solution you'd like

I'd like something clean and concise, like Select<Enum>::new("prompt message"), but I'm not sure how feasible this is with the current architecture. I'm still gonna come up with a few approache.

Describe alternatives you've considered

I've considered making wrappers around Select/MultiSelect, that would convert the enums to strings and then instantiate a Select/Multi behind the scenes. However, I'd like something better integrated. If the plan A turns out to not be possible, I'd go back to consider this.

Is your feature request related to a problem? Please describe.
I just started to play around with this as part of a CLI i'm building and was curious what suggestions you had for being able to unit test logic that contained inquire prompts? I see that internally you use prompt_with_backend

Describe the solution you'd like
I would like to be able to add unit tests around code that uses inquire prompts. One possible solution would be to expose prompt_with_backend

Describe alternatives you've considered
Not sure about alternatives but would love to hear your suggestions

Additional context

Is your feature request related to a problem? Please describe.

I'm testing out inquire in a cli app of mine and at least initially I want to just propagate errors back to main and print them with eyre::Report but the current choice of error return type (Box<dyn Error>) is making this impossible. The issue is two fold. The main issue being that Box<dyn Error> doesn't implement the Error trait so it can't be converted into an eyre::Report through From. I could work around this normally by using the eyre! macro to manually convert the boxed error into a report but this doesn't work because Box<dyn Error> also doesn't implement Send or Sync, which is required to be stored in an eyre::Report at all. This second problem could be fixed by just changing the signature to Box<dyn Error + Send + Sync + 'static> but that still wouldn't solve the From incompatibility, which is intrinsic to Box itself.

Describe the solution you'd like

Ideally I'd recommend introducing your own Error type and implement the Error trait for it. It's too early for me to say yet how it should be structured or what interface it should present, other than an opaque error type that implements Send, Sync, and Error. Ideally I'd start there, even if the Error type internally just stores a Box<dyn Error + Send + Sync + 'static> and is used the same way the current error type is.

Is your feature request related to a problem? Please describe.

Very useful to assist developers in assisting their users :)

Inspiration: https://github.com/enquirer/enquirer#-key-bindings (thanks @shimarulin)

I suggest replacing it with ui::Color::Rgb(u8, u8, u8)

I'm not yet using the crate, but what I see in the repo looks just great<3

Is your feature request related to a problem? Please describe.

The current behavior is to not render anything at all in when inputting in a password prompt. This is the standard for CLI applications.

In web, the standard is to render those little dots, or asterisks. With that approach, the user has full control and visibility of the cursor and the current input length. This is not the standard approach for CLIs, but we can support this feature for those who want/need it.

Describe the solution you'd like

The library user should be able to configure the render mode for password inputs between something like None and Masked, with None as the default.

Not sure how I missed this one. Release going out as soon as it is fixed

If the user types something and the filter does not match anything, no options are displayed to the user.

If the user then presses enter, we will try to retrieve the index of the option currently highlighted, calling unwrap on it. Since no current option is highlighted because the vec is empty, we panic.

Is your feature request related to a problem? Please describe.

Password prompt may need some kind of input indicator. Without disclosing the length of the password, just a keystroke indication. Some keyboards, especially wireless and membrane keyboards, sometimes miss a key press. In the case of creating a password, this can be a big problem, finding out the missing character will take time, if, of course, the user guesses what happened. For this reason, sometimes users want to validate the entered password before completing input.

Describe the solution you'd like

The library user should be able to enable this configuration via a flag, when building the Password prompt.

The application user, when this configuration is enabled, should be able to press a hotkey and have the current password displayed for me.

Describe alternatives you've considered

Displaying the password only while holding down a hotkey. This is not trivial (if possible) because we're in a terminal, only toggling on a press is much simpler.

Additional Context

Which hotkey would be best?

Sometimes the options are so little that allowing the user to type and press enter (specially on a multiselect) can be misleading

It looks like doc comments are the priority in the Rust ecosystem, making the README just a small front-page, which makes a lot of sense to me.

We need to refactor all of the documentation existing in the README and display it [nicely] as doc comments in order to prioritize docs.rs.

Is your feature request related to a problem? Please describe.
Just a better place for chats, and simple questions that don't require separate issues.

Describe the solution you'd like
How about having a Matrix space. (I use Element)

My use-case: I want to select over a tuple of values (String, CustomStruct). The formatted message should be tuple.0 + tuple.1.description. The whole struct doesn't implement Display, but the select dialog should use the struct's description field.

Currently that doesn't seem to be possible. Maybe lowering the bounds on T or making a change to Select would allow this? For example:

pub struct Select<'a, T, U: Display> {
    pub options: Vec<T>,
    pub item_formatter: &'a Fn(T) -> U,
}

Then the default item formatter could operate on T: Display and users could specify their own by setting the field?
This does require changing multiple parts of the code. I changed it to the idea above and had trouble fixing some compilation errors (probably due to limited knowledge about how the library works internally).

The problems that I find unergonomic is that:

1. Creating the items using format!() returns a String after calling prompt(). It's hard to map that value back to the original selected item.
2. Doing fuzzy search now also looks for partial matches inside the CustomStruct.description field. And I want to only have it look into the first tuple value tuple.0.

Is your feature request related to a problem? Please describe.

Your color palette is awful but I still need your crate, how can I make the question marks red?

Describe the solution you'd like

Allow lib users to customize the colors used in the prompts, something other than green for [anything, because I basically used green for all of the colorful stuff].

Could this be like a custom setting that you set once and all prompts use this config?

Describe the bug

The indexes on ListOption structs are relative to the output vector as opposed to the original input vector.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.

Users might already be using a terminal library for other tasks, one that is not crossterm, so ideally we should be able to use that too instead of forcing the user to have multiple dependencies for the same thing.

Describe the solution you'd like

Add a new implementation for the Terminal trait, and select different types that implement it based on feature flags.

This issue is meant to track the support for the console backend

Additional context

Following requestty's footsteps :D

Is your feature request related to a problem? Please describe.

From no-color.org:

An increasing number of command-line software programs output text with ANSI color escape codes by default. While some developers and users obviously prefer seeing these colors, many users don’t. Unfortunately, every new piece of software seems to have a different way of disabling colored text output and some software has no way at all.

Accepting the futility of trying to reverse this trend, an informal standard is hereby proposed:

All command-line software which outputs text with ANSI color added should check for the presence of a NO_COLOR environment variable that, when present (regardless of its value), prevents the addition of ANSI color.

By adopting this standard, users that prefer to have plain, non-colored text output can set one environment variable in their shell to have it automatically affect all supported software.

Describe the solution you'd like

Detect NO_COLOR env vars on the render_config instantiation.

The lib user should be able to override this, opting to print colors anyway.

It is also important to not lose any UX because of that. All prompts should be fine, except:

• Prompts with text input: #23 should be done to allow the user to know where the cursor is.
• Date prompts: a date prompt with no ansi attributes has an awful UX. Because of that #24 should be done before this task. Then we can use the built-in cursor instead of adding a background to the date.

Additional context

We should think more about the relationship between colors and behavior:

• Should a non-colored render config trigger a cursor_show with date prompts?
• Should we omit colors when the prompt is called with a custom render config but NO_COLOR is set?
• etc.

We must think better about the API

Motivation looks similar to #1, the idea here is to allow the user to input a multi-line text without having to open a text editor.

Not sure how useful this would be, as I consider #1 more important.

Edit: this is now activelly not planned to be implemented by the maintainer (me...). I'll be leaving this open in case anyone is interested in implementing it.

Is your feature request related to a problem? Please describe.

The initial_value property is properly documented in doc comments, but when reviewing the PR I forgot about the README (Text section) and the actual documentation of the Text struct, which contains an overview of the prompt API.

This is important to allow future users to easily discover this feature, in case it is useful for them.

Describe the solution you'd like

Simple lines describing the purpose of initial_value.

@irevoire pinging you in case you might be interested, but I know this is the boring part of contributing, so don't worry, I'll get to it before I release.

Currently (v0.0.6) the package is amounting to 873 kB, which seems absurd. I haven't checked but I'm pretty sure it is because of all of the '.castand.giffiles under/assets`.

We should probably use a special README file for the crates.io package, without all the gifs.

Not sure how I missed this one. Release going out as soon as it is fixed

If the user types something and the filter does not match anything, no options are displayed to the user.

If the user then presses down arrow, we check if we need to wrap around the list in case the new index is larger than the list len. We do this by executing a mod operation, which panics when the divisor is 0 (list length)

Is your feature request related to a problem? Please describe.

Does a long list have indication that only its part is displayed? As I see from the demo, a list can be scrolled but I do not notice any clue that there are extra items above or below.

Source

Describe the solution you'd like

Some sort of visual indication that the list has more options not displayed at the moment, still not sure of how that would look like.

This issue affects the three prompts containing lists: select, multiselect and text (with auto-complete suggestions).

Is your feature request related to a problem? Please describe.

Users might already be using a terminal library for other tasks, one that is not crossterm, so ideally we should be able to use that too instead of forcing the user to have multiple dependencies for the same thing.

Describe the solution you'd like

Add a new implementation for the Terminal trait, and select different types that implement it based on feature flags.

This issue is meant to track the support for the termion backend

Additional context

Following requestty's footsteps :D

Is your feature request related to a problem? Please describe.
I'd want my user to be able to read in more detail about the data he is prompted to input.

Describe the solution you'd like
The prompt would display: What's your age? (press "?" for help). Once ? is pressed, the message will be displayed (somewhere) about the formula to calculate the age. This would be more tricky to do inside the Text field type, since "?" is a valid character to put into that field type, therefore, I guess, the best way for this feature to exist, would be when the key sequence to press to get help was configurable by the developer (but I also think it depends on the context, e.g. when prompting What's the name of the project?, usually, a question mark is not a valid character to be used as a project name)

When using in bash for windows (https://gitforwindows.org/) the prompt freeze and don't let me enter a value.
It works in Powershell and cmd.
I am not sure what information I should provide. Let me know how I can help.

The behavior I'm looking for is similar to Github's CLI.

Basically something like this:

? Description: [(e) to launch nano, enter to skip]

after the user inputs: it calls the formatter, having this by default:

? Description: <received>

or, if skipped:

? Description: <skipped>

It would be great to be able to pass a slice of any type to these prompts and get the selected ones in return.

For example, you might want to pass a list of "Account"s and get a reference to the one selection back. If the Account struct implements the Display trait, we can easily print them.

In summary, the current approach requires the developer to do this:

let accounts: &[Account];
let options: &[str]; // mapped from accounts
let answer: OptionAnswer = Select::new("", options).prompt()?;
let selected_account: &Account = accounts[answer.index]; // get account back

// do something with the selected_account variable

We could use some more of this:

let accounts: &[Account];
let answer: &Account = Selec::new("", accounts).prompt()?;

// do something with the answer variable

not sure if the types defined above would actually work with the borrow-checker