byebug icon indicating copy to clipboard operation
byebug copied to clipboard

Configure `q` to quit unconditionally

Open p opened this issue 7 years ago • 12 comments

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

p avatar Dec 30 '17 00:12 p

Yup, q! quits unconditionally. I would accept a PR to configure the default behavior of q to not ask for confirmation :+1:.

deivid-rodriguez avatar Dec 30 '17 14:12 deivid-rodriguez

Okay thanks!

p avatar Dec 31 '17 15:12 p

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.

DannyBen avatar Sep 05 '19 09:09 DannyBen

I think q! is pretty reasonable

scarroll32 avatar Feb 06 '20 19:02 scarroll32

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.

p avatar Feb 06 '20 21:02 p

To anyone interested, I've been using this script to configure all installed (via rbenv, in my case) byebugs to quit unconditionally.

p avatar Feb 06 '20 21:02 p

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.

DannyBen avatar Feb 06 '20 21:02 DannyBen

That is true, Ctrl+C is a well-known exit method.

scarroll32 avatar Feb 06 '20 21:02 scarroll32

https://github.com/deivid-rodriguez/byebug/pull/605

scarroll32 avatar Feb 06 '20 21:02 scarroll32

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.

p avatar Feb 10 '20 07:02 p

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)?

DannyBen avatar Feb 10 '20 07:02 DannyBen

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.

p-mongo avatar May 01 '20 17:05 p-mongo