When using the ColorfulTheme, the tick-symbol (✔/✔) is shown as an emoji. Therefore the color is not shown anymore and you can't distinguish between checked and unchecked.

I have this problem on Windows 10 21H1 when using Windows Terminal.

A solution would be to change the prefix for unchecked items to (❌/❌) or something similar.

https://github.com/mitsuhiko/dialoguer/blob/3f16bdedf885d98a90273bd57ec243d71da1b462/src/theme.rs#L336-L337

I need to know what is the current selected item in the list while the user is navigating using the arrow keys. Is it possible?

For example you call Confirm::new("Do you want to continue").interact_opt() and on the terminal you enter CTRL+C, the cursor will remain hidden. This is acceptable though because the program terminates and does not allow you to exit cleanly.

But for example you have signal-hook to handle signals, the program will continue with the cursor still hidden. I think this should be handled by the crate as it was the one that hid the cursor

Thank you for this terrific crate!

When attempting to use the editor prompt on Windows 11, notepad.exe is successfully opened with the contents of the temporary file rendering. However, when notepad goes to save the file, it brings up a file dialog prompting you of the location to save the file. On my machine, this defaults to to ~/Documents.

However, if I exit the Rust process, the file saves fine.

I think this is due to how Windows locks files. Specifically, you can't open a file for writing if another process has an active [write] handle on it unless you just through hoops. In this crate, the tempfile crate has a handle on the file, effectively locking out other writers.

A common solution to this problem is to create a temporary directory then create and close handles on a file within that. The contents of the temporary directory will get purged on drop. But you don't have to worry about multiple processes having a handle on the temporary file. This approach also enables you to give the temporary file a nice name, which could provide UI wins.

Hi there! Thanks for creating this :)

I have some input fields that are optional. I'd like to have an API similar to this:

Maybe I'm missing something in the docs, but I don't really see how I should achieve these optional inputs.

I know you can use .allow_empty, but that doesn't really work for things like numbers.

Recently I've observed that the crate is not able to handle non-english symbols (e.g. russian/ukrainian...)

Entering special characters that consist of more than one char (like ä, ö, ü, é, ê, ...) lead to a panic.

This seems to be due to the fact that we use a range in search_term[0..cursor_pos].

I will check, if using Slices fixes the issue.

Edit: also found this while implementing #179

I found this bug while implementing #179.

As you can see in the gif in the PR, at some point the end of the prompt prints the characters for the arrow down keyboard. But this also happens with normal characters entered to the prompt.

Here's a screenshot:

Unfortunately, I was not able to spot the source of the error. Maybe someone could help here. I would like to implement a fix if someone could point me in the right direction.

The error is not directly reproducible. I tried many character combinations but it seems to only happen when I quickly enter characters, so this could be a timing issue somewhere.

I looked a little further into the issue we discussed in #130.

So far, I found a solution for *nix systems. The foreground process gets the SIGWINCH signal when a terminal is resized. I tried catching it as described here and it seems to work:

We could just create another feature that hooks into the signal and then let the screen re-render itself.

This would add 1 additional dependency if we go the way where we spawn a dedicated thread that observes the signal as in the example above (signal-hook).

Unfortunately, I don't really know how the Windows part would look like. After some quick research, maybe ResizePseudoConsole could be used for this ?! It would be nice if someone could help out here...

Hi,

is there any planning or opinion about using the full width of a terminal for listing the elements of select prompts? I mean the type of listing ls does without any arguments, so all the elements are listed in a table-like way.

Are there any plans to have this as a feature? If not, why not?

The only thing that comes to my mind where this could be a problem is fuzzy-select because of the cursor movement in the search field. But I'm sure we could think of something to make it work.

I couldn't find any issues about this, so sorry if I've overseen this if it has been discussed before.

If this is a desired feature, I would start thinking about this and implement this feature. ✌️

Hi,

When wanting to bypass a confirmation in an automated way, it does not appear possible to use the yes command, I.E:

Will just hang

Thanks for this crate, by the way. I could insert a simple terminal prompt without knowing too much about terminals!

Steps to reproduce. Take this small test programm.

1. Build and run the programm: cargo r
2. A confirmation prompt appears:

Prompt string with multiple lines: Line two?

3. Answer either yes or no (doesn't matter which).
4. My answer is displayed in the terminal.

Expected result The terminal output looks like this:

Prompt string with multiple lines: Line two yes

Actual result The prompt is printed twice, resulting in output like this.

Prompt string with multiple lines: Prompt string with multiple lines: Line two yes

Meta. Tested on both version 0.9 and 0.8 of dialoguer.

Hi there, thanks for dialoguer!

I noticed that in the default ColorfulTheme, some of the entries (prompt_suffix and success_suffix) are marked as being black:

https://github.com/mitsuhiko/dialoguer/blob/29da763bf7221d8f072bab0bdab9a29322e9e8f9/src/theme.rs#L290-L292

Since many terminal themes don't contrast "black" against dark backgrounds (and the same for "white"), it can be pretty hard to read the prompt on those backgrounds.

I'm wondering if it's possible to change this to one of the other 12 colors in the 4-bit color palette. Seems like an easy (and non-breaking) change. What do you think?

Would be great if there was a version of the text input where a user can abort by pressing Esc.

Expected behavior: When dialoguer::Input::interact is running and I press Ctrl-D, STDIN is closed and interact() returns an Err.

Actual behavior: The previous line in the terminal is replaced by the input prompt, which is moved up one line, and dialoguer keeps waiting for input. Repeatedly pressing Ctrl-D keeps moving the prompt line up, erasing past commands and prompts.

Details:

• If i call Input::interact_text instead, the prompt is not moved up one line, but the input is ignored. (Nothing happens, instead of the input being closed.)
• Select::input does not have this behavior/bug.

In some cases, we need to validate the password whether it is not strong enough, like 123456 or it contains the user's birthday number, or we require the password to be longer than a number.

to improve accessibility of select and multi select widgets a terminal cursor should be set at entries which currently highlighted with "❯".

this will greatly improve the usability of applications which depends on this library for blind people.

thank you.

Confirm::_interact_on calls Term::read_key in a loop but doesn't break out of the loop if the return value is Key::Unknown, which read_key returns if not connected to a terminal. This causes an infinite loop.