byebug
byebug copied to clipboard
Configure `q` to quit unconditionally
Problem description
I want q
to always quit byebug unconditionally. I don't ever type q
by mistake hence the added prompt, or having to append !
, are pure overhead for me.
Expected behavior
It would be great to have a configuration option of some kind to have q
quit unconditionally.
Actual behavior
Currently one has to either press q, enter, y or type q!
(I think, never actually tried that).
Steps to reproduce the problem
Try to quit byebug
Yup, q!
quits unconditionally. I would accept a PR to configure the default behavior of q
to not ask for confirmation :+1:.
Okay thanks!
I totally agree. The q!
that I always have to type is three keystrokes instead of 1 - when doing hundreds of byebug sessions a day, this accumulates to a major annoyance.
I would go as far as to make the q
unconditional quit the default behavior, but I realize this statement might ruffle some feathers...
Or - if easier to implement - at least set the default of "Really quit? (y/n)" to "y" so that pressing qEnterEnter will quit - which is slightly easier than the current situation.
I think q!
is pretty reasonable
q!
in addition to making the default yes as per @DannyBen 's comment above is ok.
q!
only is not great because it requires 1) pressing shift and 2) pressing a number row key. Not the easiest for a very frequently used command.
To anyone interested, I've been using this script to configure all installed (via rbenv, in my case) byebugs to quit unconditionally.
The truth is that Ctrl+C should simply exit as if q!
was pressed. No need to reinvent exit methods.
The problem now is Ctrl+C exits differently, and sometimes messes the terminal, and sometimes continues the run. This is simply annoying, and I really do not understand why would anyone favor unconventional exit with more keystrokes, over conventional exits with less keystrokes - it is simply counter productive.
That is true, Ctrl+C is a well-known exit method.
https://github.com/deivid-rodriguez/byebug/pull/605
The truth is that Ctrl+C should simply exit as if q! was pressed.
How would you abort a Ruby command when in byebug, if ctrl-c terminates the process? E.g. something like a database query or network operation that is taking too long.
How would you abort a Ruby command when in byebug, if ctrl-c terminates the process? E.g. something like a database query or network operation that is taking too long.
This is an edge case and should not dictate the fate of the more common case in my view. For me - 999 times out of 1000 this is not the case, and if it was, I'd be fine if byebug also kills itself when I Ctrl+C that long running process.
So, in my opinion, this should behave in one of two ways (whichever is easier to implement and makes more sense to the byebug team):
- Option 1: Ctrl+C terminates everything, as gracefully as possible, including byebug itself.
- Option 2: Ctrl+C exits byebug only if it is in its "waiting for user input" state. Otherwise, it operates normally, and terminates whatever is running, if any. This feels very natural to me - Ctrl+C = interrupt whatever is running (byebug or not).
For some inspiration - in case option 2 is on the table - think docker-compose or sinatra or foreman (I think) - First Ctrl+C is an attempt to gracefully terminate (SIGINT I believe) and a second Ctrl+C is a hard, fast kill (SIGKILL I believe).
In addition, if "Ctrl+C to exit" does not sit well with how you envision byebug, that is also fine. In that case, can we go back to allowing a quickest exit possible, using q Enter (and without asking for confirmation)?
In that case, can we go back to allowing a quickest exit possible, using q Enter (and without asking for confirmation)?
I like this option.