-
Notifications
You must be signed in to change notification settings - Fork 219
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
Added possibility of cancelling prompts #1046
Conversation
I agree with you that cancellable prompts configuration is better to be done in globally rather than per-item basis. I think that when cancelling the first prompt it would better not to exit from About the implementation. There is no need to modify prompt builders. You should rollback your modifications done in package |
Ok, I assumed the UiConfig was only for things related to look & feel, not to behaviour. That will make things easier indeed. But I'm not so sure about the other comment. I agree that returning |
I'm referring to the line ConsolePrompt.java#L199. Here we should not return
|
But how would you exit? And how would the caller detect that the user canceled? |
I guess I am missing something you would like to achieve. In order to exit the user has to answer all the prompts or to cancel he can press
|
Well first of all requiring ctrl-c to cancel is not very user-friendly, second a user would expect ctrl-c to exit the application, so what if the UI is just part of a larger application that you do not want to exit? And finally, I do not want to exit the application, I want to exit the current question to go back to the previous one so I can re-answer it without having to start the entire process over. Which is something that you suggested in #1042 which this PR (also) fixes. Perhaps there's an issue of wording here, when I created this issue I was referring to cancelling individual prompt items, not the entire prompt (with a single keystroke). Cancelling the entire prompt would be handled by repeatedly hitting ESC until you reach the first question, then hitting ESC one final time. Which is what this PR implements. |
When inside a shell, ctrl+c usually gets back to the shell. If you’re
inside a prompt, for example a readline call, the call will exit and get
back to the shell. Just try the gogo demo for example…
…------------------------
Guillaume Nodet
Le sam. 27 juil. 2024 à 18:06, Tako Schotanus ***@***.***> a
écrit :
Well first of all requiring ctrl-c to cancel is not very user-friendly,
second a user would expect ctrl-c to exit the application, so what if the
UI is just part of a larger application that you do not want to exit? And
finally, I do not want to exit the application, I want to exit the current
question to go back to the previous one so I can re-answer it without
having to start the entire process over. Which is something that you
suggested in #1042 <#1042> which
this PR (also) fixes.
Perhaps there's an issue of wording here, when I created this issue I was
referring to cancelling individual prompt items, not the entire prompt
(with a single keystroke). Cancelling the entire prompt would be handled by
repeatedly hitting ESC until you reach the first question, then hitting ESC
one final time. Which is what this PR implements.
—
Reply to this email directly, view it on GitHub
<#1046 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAUQNRUVOQLFSOPRRXUCPLZOPASBAVCNFSM6AAAAABLMSAL3CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJUGE4DOOJRGU>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
@gnodet this is about not wanting to go back to the shell, but simply backing up a single question. For example, the user selects an option, in the next prompt (item) they realize they've made the wrong selection and want to back out to the previous question. You might say "just ctrl-c and restart" but there might be a whole bunch of reasons the user doesn't want to do that (one reason might be that they've already answered a dozen other prompts before and don't want to repeat all of them) |
Ok, I think I have understood the point. For example you can wrote an app that prompt question(s) before you have called IMHO it is enough to have configuration option only for the first prompt cancellation. As a default the first prompt is not cancellable in order to keep the backward compatibility. If the first prompt is not cancellable we will redraw the first prompt when trying to cancel it. In a case the first prompt is cancellable |
Indeed! And the idea of repeating the first question (if cancellable is false) to maintain backward compatibility is a good options as well. But just to confirm: does that mean that you are okay with adding ESC to cancel by default to all key bindings? |
Yes |
Updated the PR according to the feedback. |
@mattirn have you had some time to look at the new code? Btw, my idea was to flatten the commits into a single one, I haven't done so for now so you can look at the changes I made. Once you're okay with the new code I can either flatten manually or you can do so at the moment of merging, whatever you prefer. |
When cancelling the first prompt of |
4e653e3
to
2315824
Compare
The only thing is that all of a sudden I have to hit ESC twice to have it registered. It's almost as if the ambiguous timeout doesn't work anymore. Investigating... Edit: the code doesn't seem to honor the timeout. In this line https://github.com/jline/jline3/blob/master/reader/src/main/java/org/jline/keymap/BindingReader.java#L83 the peek simply blocks forever even though the value passed is 150 (checked with debugger). Edit2: this only seems to happen in a Git Bash console on WIndows, it doesn't happen in a CMD window (using jansi), nor on my Fedora Linux system. |
2315824
to
948c8c4
Compare
@quintesse , your pull request looks good to me. Please, could you add in
and in try-block catch I agree that the problems you have found in |
@mattirn I'm not sure if I understand what you want me to do exactly? Do you want to make it possible to treat CTRL+C as an alternative to ESC to cancel a prompt item instead of exiting the application? If so, shouldn't that be configurable? Because that seems like a behaviour most people wouldn't want by default. (Which other application behaves like that? I don't know of any. In fact I would be very angry with any CLI application doing that, if I hit CTRL+C I want an app to exit) |
I would like you to register signal handler to your terminal and catch The desired behavior of There is no need additional configurations because the developer already has a full control to implement |
Cancelling a prompt by hitting the ESC key makes it go back to the previous prompt. By default, if we're already at the fist prompt we'll repeat the question until the user either answers it or forcefully quits the application. If on the other hand the `cancellableFirstPrompt` option of `UiConfig` has been set to `true`, the `prompt()` method will return `null`. Fixes jline#1035
948c8c4
to
9907772
Compare
Ok, so it's only to show how to handle CTRL+C in an app. That confused me a bit because no CTRL+C handling is being done in |
Cancelling a prompt by hitting the ESC key makes it go back to the previous prompt. If we're already at the fist prompt the result returned will be
null
.Fixes #1035