Remove handling of CTRL+C about prompts HOT 28 CLOSED

This is completely unnatural if you ask me, and believe it or not but I arrived in this issue voluntarily, because of this strange, at least to me, ctrl+c behaviour (and double ctrl+c doesn't seem to work to me).
For instance if I want to close the cli after a ctrl+c has been pressed, I've to check the empty answer and call process.exit(1)

At least let's write it in the docs

from prompts.

-1 vote on 'Remove'

@FoRVaiS what you mean by voting -1? The proof why it should be removed is in your native expectation/assumption to click CTRL+C (seen in your issues) to exit a program, when you encounter something strange.

Probably 90% of the terminal world have expectations Ctrl+C to kill, even on Windows and I don't understand why we should commenting all of that at all. 🚀

I'm not argue or something, just can't believe.

from prompts.

Don't know why implementer of such CLI should think about greedy option at all.

And also it's not breaking change.

from prompts.

Prompts run as a part of other CLI programs. I don't want to have people accidentally quit the main program when they try to abort prompts.

I agree abort should quit the prompt and prompt loop and don't need any options. But it should abort and return control to the program.

It's up to that program to decide what to do. Worst case you'll have to hit ctrl+c twice when you're in a prompt and want to quit the whole thing. Better safe than sorry.

from prompts.

@kjbrum you can. With the onAbort i believe or onCancel.

The whole thing was that i still don't understand why we should think for "greedy" option at all as implementers of such CLIs. But anyway.

from prompts.

Not sure what I think of this one. It only prevents your program from being killed while waiting for user input. What do you think @lukeed?

from prompts.

Haha. If user want to kill it, let him kill it. Mostly everything uses Ctrl+C for kill, except copy-pasting but it's in rare cases - browsers and etc.

from prompts.

Alright. Let's make a poll (Click to vote)

from prompts.

Oh that poll is glitched... If a user goes back to 'previous page', it increments the counter... I'm also pretty sure i can click it again to stack votes... :) -1 vote on 'Remove'

from prompts.

Right, thanks for letting me know That means it's 1/1 now

from prompts.

@olstenlarck Oh, the -1 was because i voted twice by accident. Right now its:
Remove: 2
Keep: 1

from prompts.

I don't see any problems with the poll. I can't vote more than once and tried your way too - no glitches.

from prompts.

Then i guess someone had voted immediately after i did. I guess score remains 3 to 1 :P

from prompts.

Sorry for silence -- I'll spin something up today to see how it feels.

from prompts.

It's definitely smooth to have the ability to "skip" prompts. However, I could see this being really unexpected for the majority of cases.

I would think that the best bet to make this configurable, with immediate exits being the default.

The current behavior could be configured globally (within prompts()) or on a per-prompt basis (via a optional: boolean key).

from prompts.

Agree. Let's make this optional. What makes most sense global or per-prompt basis?

from prompts.

Default to CTRL+C to terminate program on a per-prompt basis

from prompts.

Thanks to @lukeed recent refactor this shouldn't be that hard to implement. I even think it can be done in the prompt loop

from prompts.

On second thought, I think they're two separate features.

The global one can be implemented on the main handler. Right now, the onCancel is called only when cancels are received. There aren't any errors anymore. So something like this

} catch (err) {
  quit = !opts.greedy || onCancel(prompt)
}

from prompts.

I like the greedy naming!

from prompts.

Don't why there should be tons of keystrokes - currently it is possible to skip question with Ctrl+D and Escape, it's pretty enough and expected. Just document it and don't do anything for the Ctrl+C. :)

from prompts.

Each individual prompt element can be quitted. The abort action can be activated in a few different ways: ctrl+c, ctr++d, abort and esc (action.js). This makes sense when you use them on their own and pretty much the expected behaviour for all CLIs.

The question is what happens when your in a question loop. I guess the greedy option is the way to go. But why would you ever "skip" a question anyway - wouldn't that just be a prompt with a default value then? Or should it abort and not write to the response object at all?

What value should an aborted prompt resolve to?

This is an aborted loop:

We'll always have to do some logic on abort to clean up after ourself. It's not possible to just remove ctrl+c handling.

I implemented @lukeed greedy here: https://github.com/terkelg/prompts/tree/quit

from prompts.

why would you ever "skip" a question anyway - wouldn't that just be a prompt with a default value then?

exactly.

The abort action can be activated in a few different ways: ctrl+c, ctr++d, abort and esc (action.js).

exactly. it is too much and I dont see why should handle ctrl+c. The default behavior for this keystroke for most CLIs is to quit the whole program, no matter what it does.

And here are not talking to remove some feature and dont allow end users to abort some question - they still will be able to do it. But would allow others to quit the whole program, as they may expect. And you already seen one such user, and in future there will be more and more issues about that. Currently, they literally cant do it.

from prompts.

I'm okey with double Ctrl+C.

from prompts.

Am I understanding correctly that there isn't any way to know if a user cancelled the prompts by hitting ctrl + c?

from prompts.

This is completely unnatural if you ask me, and believe it or not but I arrived in this issue voluntarily, because of this strange, at least to me, ctrl+c behaviour (and double ctrl+c doesn't seem to work to me).
For instance if I want to close the cli after a ctrl+c has been pressed, I've to check the empty answer and call process.exit(1)

At least let's write it in the docs

I had to do the same trick (check if the result is not empty and then exit the process with 130 code):

    if (!answers.username || !answers.password) {
        const SIGINT_CODE = 130;

        process.exit(SIGINT_CODE);
    }

But having to do this for every prompt was really tedious. Had to switch to Inquirer.js only because of this issue..

from prompts.

@llirikkk, totally agree.

@llirikkk: But having to do this for every prompt was really tedious. Had to switch to Inquirer.js only because of this issue..

You can always make a wrapper around the onSubmit or wherever that snippet above is.

Something like this, worth nothing

function onSubmit(fn) {
  return (prompt, answer) => {
     if (!answer.username || !answer.password) {
        const SIGINT_CODE = 130;

        process.exit(SIGINT_CODE);
        return
    }
    fn(prompt, answer)
  }
}

Yea, it's not the best way and definitely such workarounds aren't THE correct/best WAY, but is (even better) possibility than switching to bigger and slower Inquirer. Or at least you can try enquirer if you want so, which is mega configurable too and zero-dep.

Seeing @terkelg marked it as v3... that will be great! :)

from prompts.

This makes debugging scripts an absolute pain. It doesn't help prompts doesn't work with the vscode debugger.

from prompts.