-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Helper methods for Ctrl+C Support #1
Comments
After a proper review of the code, I don't see any reason for getaction to be cancellation unsafe. |
Ph4ntomas
changed the title
Cancellable getaction (for Ctrl+C Support)
Helper methodes for Ctrl+C Support
Mar 6, 2024
Ph4ntomas
changed the title
Helper methodes for Ctrl+C Support
Helper methods for Ctrl+C Support
Mar 6, 2024
As a small PoC, i've added a discard public function pub discard(&mut self) {
eprintln!();
self.do_reset = true;
} and changed the main function from the example like so: async fn main() -> eyre::Result<()> {
let mut cli = Cli::new()?;
let mut exit = false;
let mut discard = false;
while !exit {
if discard {
cli.discard();
discard = false;
}
tokio::select! {
_ = tokio::signal::ctrl_c() => { discard = true }
act = cli.getaction() => {
match act? {
Action::Command(cmd) => runcmd(cmd, &mut exit),
Action::AutoComplete(cmd) => autocomplete(&mut cli, cmd)?,
Action::NoAction => exit = true,
};
}
}
}
println!("Hello, world!");
Ok(())
} |
Ph4ntomas
pushed a commit
to Ph4ntomas/tokiocli
that referenced
this issue
Mar 19, 2024
This implement what I suggested in guillaumepellegrino#1, and add it to the example implementation. Using the discard function to trigger a reset, we can flush the cli. With this, it's possible to use tokio's signal handler to handle ctrl+c cleanly.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It would be nice to be able to use ctrl+c to flush the command-line, and re-print the prompt.
The SIGINT (or windows equivalent) can be handled using tokio::signal::ctrl_c. However, this override the signal handler, which should not be done by the library, especially for cases where ctrl+c is not to be used to flush the buffer.
For this reason, signal handling should (in my opinion) be done on the application side, and not by tokiocli.
The way I see it, this could be achieved by having a cancellable getaction, either via an optional parameter, global cli configuration, or an alternate way of calling getaction, which would add this behavior.
This can be implemented in tokiocli via select! macro and `tokio_util::sync::CancellationToken, or by ensuring that get_action is cancellation safe.
The flush mechanism should be kept separate, or at the very least opt-in too.
Splitting the mechanism that pause inputs from the one that empty the internal buffer would also allow one to retrigger a print of the whole line, in case the calling application wants to, e.g. print some log, then restore the line, so the user can resume typing.
I can implement that functionality, but I'd like to know if you have any issue/preferences regarding this, or any input on how to better handle the whole buffer flushing/re-drawing.
The text was updated successfully, but these errors were encountered: