Added 'History' support, along with default SimpleHistory implementation and tests

[mikecvet]

This is a suggested implementation of prompt history for Text proposed in #224

The diff hooks into the key bindings for up and down arrows, currently used for suggestion navigation, to also potentially navigate upwards and downwards through prompt history.

A user can set a prompt history when creating their new Text via something liek

    let input = Text::new(&terminal_prompt)
      .with_history(SimpleHistory::new(history_string_vec.clone()))
      .prompt();

[mikaelmello]

I think this is pretty great, thanks a lot for the contributions!

The diff hooks into the key bindings for up and down arrows, currently used for suggestion navigation, to also potentially navigate upwards and downwards through prompt history.

This made me think of an approach that I believe would work really well, let me know your thoughts:

On a fundamental level, this is another approach on giving suggestions to the user. Think about normal bash "up and down" vs fzf which displays a list to be selected.

Also, the current suggestion approach (a selection list) obviously conflicts with this in terms of keybindings, which leads me to think they are exclusive to each other.

I feel that inquire is reaching a stage where it's bloated with a ton of different pieces to use but it's missing a better UX story. I think there is a path here for a unified approach to suggestions/auto-completion/history

[mikecvet]

I think this is pretty great, thanks a lot for the contributions!

Thanks!

On a fundamental level, this is another approach on giving suggestions to the user. Think about normal bash "up and down" vs fzf which displays a list to be selected.

Yes, agreed.

Also, the current suggestion approach (a selection list) obviously conflicts with this in terms of keybindings, which leads me to think they are exclusive to each other.

I feel that inquire is reaching a stage where it's bloated with a ton of different pieces to use but it's missing a better UX story. I think there is a path here for a unified approach to suggestions/auto-completion/history

Yeah, while building this feature, and largely pairing it with autocomplete side-by-side, it seemed like supporting a generalized "navigation" framework, which can hook into suggestions, history, or whatever else, would be the right way to go. I'd love to be able to define some kind of callback or handler for specific keystrokes within my application, and feed outputs back into the prompt

[Baarsgaard]

I've been pondering over something like a "Query" prompt similar to what you're both describing.
My notes which I haven't finished thinking through:

• Allow user to write an arbitrary "query" and get list of results served by fetcher/evaluation/query handler function.
• Trigger the query handler after every keystroke but with a configurable debounce delay (Avoid spamming an endpoint or blocking the thread).
  • Ctrl+Enter or Shift+Enter could trigger the handler manually.

    a retry for non-deterministic/waiting for something async to finish?

• Tab changes mode between selection and completion

  • Starting in completion/selection mode is a boolean config.

  • Selection mode:
    Selecting a subset returns the subset, exactly like MultiSelect
    Selecting nothing takes the entire range provided, or a keybind for selecting everything similar to MultiSelect.

    Limiting this to a MultiSelect could be wrong, and could instead be a configuration option allowing "Single" Select behavior if set.

  • Completion mode:
    Identical to "Single"Select behavior where a list of completion items is provided and one can be applied by selecting it.

    Completion mode requires a separate completion handler function with a similar debounce mechanism as the one defined for the query handler.

    Once selected modify the query and either

    1. Exit completion mode and trigger query handler.
    2. Re-enter completion mode, trigger completion handler, and offer a new list of completions/suggestions.
       Tabbing out discards the completions and triggers the query handler to fill the result list.
• A must-have is allowing the implementation to provide a default/pre-filled query field.
  This is quite useful in some cases.