However, some users may perceive "ESC" as a command to go back and modify the previous item (even though this functionality is not implemented). How should we strike a balance?

In lieu of that functionality being implemented, I don't believe "a balance" is necessary.

I do agree, in an ideal world <Esc> would go back a step, but without bi-directional navigation, it should (IMO) just exit.

@rschristian I agree with your point, but I believe not everyone wants ESC as the way to terminate a program.

In the terminal, pressing the ESC key is typically interpreted as the start of a special character or escape sequence, rather than a command to terminate the current task. The ESC key is often used to trigger control sequences in the terminal, such as navigation or performing specific actions in interactive interfaces.

In contrast, CTRL + C is a common key combination in the terminal that is used to send an interrupt signal (SIGINT) to the running process. Pressing CTRL + C will terminate the currently running task and notify the operating system to stop the execution of that process.

CTRL + C is a standard termination signal that is widely used to terminate processes, while the meaning of the ESC key can vary depending on the terminal configuration and the requirements of the running program. Therefore, using CTRL + C to terminate tasks in the terminal is a widely accepted convention and practice.

Anyway, I don't think it's something that "clack" should do. If you want your CLI tool to support ESC as a way to terminate, you can easily implement it by listening to events using "readline".

like this:

import readline from 'node:readline'

const rl = readline.createInterface({
    input: process.stdin,
    output: process.stdout
  })

  rl.input.on('keypress', (str, key) => {
    if (key.name === 'escape') {
      console.log('ESC key was pressed')
      rl.close()
    }
  })

...this feels like a ChatGPT response to be honest, and I'm not quite sure what your issue with this is anyways? If you prefer to keep using <C-c>, adding another (widespread) keybind shouldn't hinder you.

Regardless, as I mentioned in the first post, I'm already patching clack with the diff provided. No reason to mess with readline really.

@rschristian I apologize if I have offended you. My point is that Ctrl + C is the standard signal for terminating a process in the terminal, rather than Ctrl + C or Esc. If you prefer using Esc, you can implement it yourself using patch-package or readline according to your own needs, rather than asking for "standard" support in clack to cater to your personal preference.

By the way, I'm working on a prompt that supports the option to go back and modify previous choices, similar to this: https://github.com/lnquy065/inquirer-interrupted-prompt.

If Esc becomes the standard, it would indeed hinder my progress.

No offense taken, your comments just read rather bizarrely, similar to AI-generated content, as they seem to miss previous context. Fair enough if they're not.

My point is that Ctrl + C is the standard signal for terminating a process in the terminal, rather than Ctrl + C or Esc.

As I mentioned:

I do agree, in an ideal world <Esc> would go back a step, but without bi-directional navigation, it should (IMO) just exit.

Going back a step, in a tool without that functionality, is identical to exiting. I'd love if Clack could support bi-directional nav and <Esc>'s behavior could reasonably change without breaking functionality in any way if there were added in the future.

Anyways, it's up to the actual maintainers to decide, I think I've made my case for it.

@rschristian my comments may seem strange because English is not my native language, and I used a translation software to write my comments. Don't worry too much about it.

At the beginning, I already said, "How should we strike a balance?" But you might have misunderstood my intention or the translation software didn't accurately convey my message. What I meant was that if ESC becomes the standard, it would cause inconvenience for users who don't prefer ESC as a termination signal and for users who need to use ESC for a return function.

Similar issues: SBoudrias/Inquirer.js#148

I hope you didn't misunderstand my point, and I didn't misunderstand yours either.

I agree with your point that CLI tools can be customized based on specific use cases or personal preferences. However, I believe that it goes beyond the scope of what "clack" should consider.

What I meant was that if ESC becomes the standard, it would cause inconvenience for users who don't prefer ESC as a termination signal

As mentioned multiple times now, I do not believe it should be a termination signal long-term (if that can be helped, anyways, relies on bi-directional movement through the prompts), but "back" and "exit" are synonymous in 1-step programs (which Clack currently is).

and for users who need to use ESC for a return function.

I mean, that's patching Clack's behavior, so causing an inconvenience isn't really an issue there... Possible behavioral changes should be expected when patching, after all.

I agree with your point that CLI tools can be customized based on specific use cases or personal preferences.

I wasn't making that point at all, no. <Esc> to go back/exit (if last step) is the standard in dozens of tools. This isn't personal preference.

But again, up to the maintainers. They can decide.