Here is a first beta of the order_select question (Discussed in [#13]), but i'ts not complete.

I still have to :

• [x] implement the automatic test module, since I tested it manually

I intentionally not implemented many functions in the builder (choice, choice_with_default, separator, default_spearator, choice_with_default) for the following reasons :

• Since the user will mix the order of the options in the list, separators aren't necessary,
• "Choice" and "choice with default" don't seem necessary anymore to me, because the programmer can compose the list and set the order of the options before building the question.

Let me know if you want changes in the code.

Only tested on Windows 11.

Hey there! I love this library. I noticed a bug in the editor code, though, that I thought I might be able to fix for you.

My EDITOR environment variable is set to subl -w because Sublime Text needs a -w to wait until the window is closed. However the code in requestty assumed EDITOR was just a single executable and thus I would get a no such file or directory error when the command tried to execute.

To handle this I've added shell-words to handle splitting (since splitting commands with arguments and quotes is non-trivial) and this seems to work.

I can run my program with EDITOR=vim and it works as well as EDITOR="subl -w" and it works. So this seems to still work for the default case but now also supports environments where users have arguments baked into their EDITOR variable.

#Why ? Certains programs need to let the user choose the order of certain things. For example, a tool allow to combine data all together and the user can choose in which order to combine it.

#How will it work ? Similarly to Multi-Select : the space key is used to select an option, the arrows to navigate threw or move the selected option and the enter key to finalize the order.

For the returned value, it can be a Vector containing the ordered IDs of the options. The IDs will be just the index of them in the list given to the question constructor.

I don't think the separators sill be necessary, because the user will mix the options up.

It seems to me that if I specify a default for an input prompt, and then the user just presses Enter, we get an empty string returned, rather than the default value. The docs say the default should be returned, and that is also what would help us :)

Hello,

Is it possible to have some fish-style greyed-out autocompletions with the first autocompletion? Like https://fishshell.com/assets/img/screenshots/autosuggestion.png Then tab would autocomplete to that (while still doing what it's currently doing, cycling through the possibilities of course). It would just be a display change.

That would help the user know that they can autocomplete.

Hi there! Hopefully this is actually an issue with this library, unlike the last issue I raised 🙈

If a free text input prompt spans multiple lines, the cursor shows in the correct position horizontally, but on the first line of the prompt, like so:

(Notice the underscore on the "u" in "your")

Typing input moves the cursor horizontally as expected, but it remains on the first line as opposed to where the input actually is

Tested on Windows & Linux, issue present on both

Most CJK characters are as wide as two ASCII characters; they should also take up twice the width on the terminal.

Therefore, if you pass CJK characters into the prompt or input when using this library, the cursor position will be abnormal.

use requestty::*;

fn main() -> Result<()> {
    prompt_one(
        Question::input("name")
            .message("你叫什么名字")
            .default("王小明")
            .build(),
    )?;
    Ok(())
}

Using version 0.4.0 on Ubuntu linux, I see the following when inputting data for prompts:

[/home/xxx/.cargo/registry/src/github.com-1ecc6299db9ec823/requestty-ui-0.4.0/src/input.rs:125] self.backend.size() = Ok(
                                                                                                                              Size {
                                                                                                                                            width: 372,
                                                                                                                                                               height: 74,
                                                                                                                                                                              },
                                                                                                                                                                                )

This appears to come from a dbg! on line 125 of input.rs. That sends the message to stderr. I'm using Gnome terminal, but it also happens with xterm. Oddly, this does not happen in rxvt or the vs-code terminal.

It's probably best to remove this line, as the rust docs say:

The dbg! macro works exactly the same in release builds. This is useful when debugging issues that only occur in release builds or when debugging in release mode is significantly faster.

Note that the macro is intended as a debugging tool and therefore you should avoid having uses of it in version control for long periods (other than in tests and similar). Debug output from production code is better done with other facilities such as the debug! macro from the log crate.

thread 'debug::test' panicked at 'adjust_page called before height or render'

stack backtrace:
   0: rust_begin_unwind
             at /rustc/97032a6dfacdd3548e4bff98c90a6b3875a14077/library/std/src/panicking.rs:517:5
   1: core::panicking::panic_fmt
             at /rustc/97032a6dfacdd3548e4bff98c90a6b3875a14077/library/core/src/panicking.rs:101:14
   2: core::option::expect_failed
             at /rustc/97032a6dfacdd3548e4bff98c90a6b3875a14077/library/core/src/option.rs:1615:5
   3: core::option::Option<T>::expect
             at /rustc/97032a6dfacdd3548e4bff98c90a6b3875a14077/library/core/src/option.rs:698:21
   4: requestty_ui::select::Select<L>::adjust_page
             at [:REDACTED:]/requestty-ui-0.2.0/src/select/mod.rs:279:24
   5: requestty_ui::select::Select<L>::maybe_adjust_page
             at [:REDACTED:]/requestty-ui-0.2.0/src/select/mod.rs:382:13
   6: requestty_ui::select::Select<L>::set_at
             at [:REDACTED:]/requestty-ui-0.2.0/src/select/mod.rs:144:17
   7: requestty::question::select::Select::into_prompt
             at [:REDACTED:]/requestty-0.1.2/src/question/select/mod.rs:113:13
   8: requestty::question::select::Select::ask
             at [:REDACTED:]/requestty-0.1.2/src/question/select/mod.rs:130:34
   9: requestty::question::Question::ask
             at [:REDACTED:]/requestty-0.1.2/src/question/mod.rs:520:40
  10: requestty::prompt_one_with
             at [:REDACTED:]/requestty-0.1.2/src/lib.rs:283:15
  11: requestty::prompt_one
             at [:REDACTED:]/requestty-0.1.2/src/lib.rs:259:5
  12: clashctl::debug::test
             at ./src/debug.rs:4:5

Minimum reproducable case:

#[test]
fn test() {
    use requestty::{prompt_one, Question};
    prompt_one(
        Question::select("Debug")
            .choices(&["1".to_owned(), "2".to_owned(), "3".to_owned()])
            .default(0)
            .build(),
    )
    .unwrap();
}

This is the exact code produced the above backtrace. Only when default = 0 will make the program panic.

Hi there!

First of all, thank you for the crate! It's a lovely simple way to start interacting with users in the terminal

I have the following function:

pub fn get_api_key(client: &reqwest::blocking::Client) -> Result<String> {
    let question = Question::input("api_key")
        .message("Please enter in your OMDb API key. If you need to, visit their website to get one (https://www.omdbapi.com/apikey.aspx)")
        .validate(|api_key, _| test_api_key(api_key, client))
        .build();
    Ok(requestty::prompt_one(question)?.try_into_string().unwrap())
}

It compiles fine, however regardless as to what the user inputs (and whether or not it should be valid), I get the error builder error: unsupported pair.

I can't work out what I'm doing to cause the error, any pointers?

When we resize the terminal, the view height doesn't change.

When i change to a greather height, the size stays the same and requestty works fine. But when i change to a small height, enough to hide a part of the requestty view, it panics and show this error :

thread 'main' panicked at 'attempt to subtract with overflow', C:\Users\noval\rust\requestty\requestty-ui\src\input.rs:150:28
stack backtrace:
   0: rust_begin_unwind
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library\std\src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library\core\src/panicking.rs:142:14
   2: core::panicking::panic
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library\core\src/panicking.rs:48:5
   3: requestty_ui::input::Input<P,B>::adjust_scrollback
             at C:\Users\noval\rust\requestty\requestty-ui\src\input.rs:150:28
   4: requestty_ui::input::Input<P,B>::render
             at C:\Users\noval\rust\requestty\src\question\mod.rs:567:45
   9: requestty::prompt_one_with
             at C:\Users\noval\rust\requestty\src\lib.rs:283:15
  10: requestty::prompt_one
             at C:\Users\noval\rust\requestty\src\lib.rs:259:5
  11: requestty_test::main
             at .\src\main.rs:9:23
  12: core::ops::function::FnOnce::call_once
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f\library\core\src\ops/function.rs:248:5

The error occurs with OrderSelect (not yet implemented, see [#16]) and MultiSelect. It doesn't seems to occur with one-line questions, like confirm or float.

Tested with PowerShell in VSCode.

It would be nice if you could filter a select list by typing part of an option so you can choose it without having to scroll through a whole list if you already know what you want.

I can try and add this myself if this is a feature you'd be cool with.

thread 'main' panicked at 'attempt to calculate the remainder with a divisor of zero', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/requestty-ui-0.3.0/src/prompt.rs:149:14
                                                                       note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I am getting the following error when I am using the requestty = "0.3.0". Docker Engine version is: 20.10.12.

But I'm not getting the same error in Ubuntu.

UST_BACKTRACE=1 environment variable to display a backtrace`

This error occurs when the questions cannot be displayed on the screen this should not really error out unless there is some loop back error , its really easy to go off limit when using integrated terminal and having bunch of options

not sure if this is intended or there is a workaround to this?

I've noticed some unicode symbols (e.x. the SelectBuilder cursor) is not supported by the windows command line cmd.exe. Having the option to set a custom char would be a nice addition to the library in my opinion. I'm still getting used to the concepts of the rust language itself so i don't have a concrete solution for this, but im assuming the chars for the library are defined as constants somewhere. My proposal is allowing them to be set to a custom char in the same way that PasswordBuilder is able to set a custom masking char, to keep everything nice and consistent.