mikaelmello / inquire Goto Github PK
View Code? Open in Web Editor NEWA Rust library for building interactive prompts
Home Page: https://docs.rs/inquire
License: MIT License
A Rust library for building interactive prompts
Home Page: https://docs.rs/inquire
License: MIT License
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.
Very useful to assist developers in assisting their users :)
Inspiration: https://github.com/enquirer/enquirer#-key-bindings (thanks @shimarulin)
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
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.
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:
Additional context
We should think more about the relationship between colors and behavior:
We must think better about the API
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)
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...
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.
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:
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
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.
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
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.
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
for stuff like "order in which I will watch movies this summer"
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:
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).
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.
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.
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.
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?
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.
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.
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?
Not sure if useful, but it would be fun
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.
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.
Describe the bug
Strings rendered by the backend that contain new-line characters (\n
) are not properly handled. Creating two problems:
\r
to these strings.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
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
I suggest replacing it with ui::Color::Rgb(u8, u8, u8)
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.
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
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!
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.
Describe the bug
The indexes on ListOption structs are relative to the output vector as opposed to the original input vector.
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.
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.
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.
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.
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.
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:
Expected behavior
The error message keeps its position on the screen.
Desktop
Additional context
Can be related to #15
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.
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:
git clone https://github.com/mikaelmello/inquire
cd inquire && cargo run --example expense_tracker --features="builtin_validators date"
payee
field (third field) with the tab
key as shown in the demoExpected 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
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 :)
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:
length!() ; length() ; Length::new()
.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.
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.
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.
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()?;
I'm not yet using the crate, but what I see in the repo looks just great<3
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>
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:
format!()
returns a String
after calling prompt()
. It's hard to map that value back to the original selected item.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.
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.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.