Support multiline inputs in non TTY contexts#518
Conversation
|
I have also added support to handle backspace characters in non TTY mode. This makes the following work: ➜ echo -e "([)\n\b\b\n])" | cargo run --example input_multiline 2> /dev/null
Input: ([
]) |
|
Sorry, but there should be no ANSI escape sequence (colors) in the input stream. |
I don't really understand what you mean. I don't think I have added anything ANSI dependent in the input stream. Are you referring to Or are you referring to the output stream, and I need to filter out ANSI sequences in the messages from the validator? |
Sorry I was completely wrong ! |
|
Since I have fixed an edge case in the way the ➜ echo -e "([)\n\b\n])" | cargo run --example input_multiline 2> /dev/null
Input: ([
])Notice how I don't need to backspace the |
|
Thanks and sorry for the long delay. |
|
No worries, thanks for reviewing and taking the feature in! 😄 |
|
Version 9.0.0 released. |
This PR add supports for multiline inputs (via the
ValidatorAPI) for the case where stdin isn't a TTY (or is an unsupported terminal).I have added a new example
input_multilineto make quickly showcase how this works.This lets us do:
And have readline correctly read this as a single multiline input instead of 3 separate inputs (if it was called in a loop).
Even in the single line case, there was a difference between the TTY and the non-TTY versions of readline: the non-TTY version would keep the trailing newline character.
My main motivation for this change is to be able to easily test a REPL made using
rustylineby piping my inputs in without having to mock the TTY part of it. It also makerustylinemore consistent this way.