awslabs
Implement transaction countdown timer using ANSI escape codes
Issue #, if available: #203
Description of changes:
This is a bit of a hacky change until I figure out how to make asynchronous calls to draw prompts using the rustylines, or use another readline implementation altogether.
This solution relies on the customer's terminal handling the ESC7 and ESC8 ANSI escape codes as Save Cursor Position and Restore Cursor Position, respectively. This is supported in VT100 Mode, which is apparently supported by the xterm terminal emulator.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
What happens when the screen is already full? Does the timer overwrite previous input/output?
Yes- the current implementation uses the erase line ANSI Escape Code const ERASE_LINE: &str = "\x1b[2K"; on the first line in the terminal.
It seems to me the thing we're trying to warn customers about is that the query they're about to input could fail. And so the UI feedback should be close to the input. Having it far away (worse case, top left while the cursor is bottom right) may make it hard to spot or intuit what it means. And, having it override previous results is annoying. One use-case for the CLI is to do a bunch of queries and then copy the interaction to something (like a github issue). So I think this needs to be unobtrusive as a design requirement. What are your thoughts?
I agree. Ideally, the * in the prompt should be replaceable with a countdown timer.
I wonder if the timer should be tightly coupled with the transaction lifecycle, though. If the timer ends prematurely, should the transaction automatically be aborted, bringing the user back to the default blue prompt?
I agree. Ideally, the * in the prompt should be replaceable with a countdown timer.
That sounds reasonable.
I wonder if the timer should be tightly coupled with the transaction lifecycle, though. If the timer ends prematurely, should the transaction automatically be aborted, bringing the user back to the default blue prompt?
I don't think so.
I implemented a readline library which accomplishes the live timer using tokio's async/await functionality. However, my implementation uses an entirely separate approach than the one rustyline uses, which would make integration rather difficult. How do you think we should proceed?
I implemented a readline library which accomplishes the live timer using
tokio's async/await functionality. However, my implementation uses an entirely separate approach than the onerustylineuses, which would make integration rather difficult. How do you think we should proceed?
I think it's reasonable to try cram this feature in within the confines of rustyline, then as a separate item figure out if rustyline is the right longterm bet.
The idea of the prompt having a "timer space" in it that we are allowed to fiddle with is pretty reasonable. It provides a decent opt-in/out experience.