Add keybind to cancel confirmation with 'n'

[pindab0ter]

In confirmation boxes, you're able to confirm with either Enter or y. Cancelling is done with Esc, but not with n, as you might expect.

I noticed myself trying to dismiss this prompt with n a lot of times and failing, so I added the option to do so.

In my opinion, this doesn't warrant any tests because it only adds a shortcut for confirmation dialogues.

[jesseduffield]

Coincidentally #2097 touches on the same thing. I think we should remove the 'y' keybinding to remove this confusion, and to free up more space for menu-specific keybindings

[jesseduffield]

CC @mark2185

[mark2185]

That's why I opened the PR, actually.

Even though I never use y/n, I'm not really comfortable from straying away from it.

[pindab0ter]

Coincidentally #2097 touches on the same thing. I think we should remove the 'y' keybinding to remove this confusion, and to free up more space for menu-specific keybindings

I just want to express my preference for being able to use y/n.

[jesseduffield]

You've convinced me! One thing :)

[pindab0ter]

I’ll solve the merge conflict tomorrow.

[pindab0ter]

Rebased on main and resolved the merge conflicts.

One small hiccup is that you can also dismiss non-question dialogues with ‘n’. For example: “You cannot delete the checked out branch!” can be dismissed with ‘n’ now, too. Semantically this is odd, but in terms of muscle memory it might be a good thing.

[mark2185]

Maybe the Alert and Confirm panels should each be its own, separate, thing.

[jesseduffield]

This relates to the argument I was making in #2097 i.e. the muscle memory can cause confusion. I don't mind having y/n work in an alert panel (each keybinding would just close it) but if you're used to using 'n' to close a popup panel and then a menu panel appears where 'n' is tied to an actual menu item (e.g. 'create _n_ew branch') that will cause confusion. So rather than build up the muscle memory of using enter/escape for everything, the user could get themselves in trouble with using y/n sometimes and enter/escape other times.

[mark2185]

the user could get themselves in trouble with using y/n sometimes

Just to recap my suggestion:

• alerts have only Escape/Enter
• confirm panels have [Y/n] (like unix tools do) where the user can press either:
  • y to confirm
  • Enter for the default value (in this case Y)
  • Escape to abort

To be frank, I'm also getting the feeling this complicates things, but I don't think it's due to muscle memory, but to the UX since we can't type y and then confirm the input with Enter

[jesseduffield]

@mark2185 I know that some CLI tools take that approach but I have some issues with it:

1. It's rare that you'll have a [y/N] question (i.e. where the default is 'no') and when you do, the user might not realise that no is the default from a quick glance
2. Given how often the user would press 'y' to mean 'yes' and enter to also mean 'yes', they'll assume the keys do the same thing and then be surprised when they don't.
3. If we make it so that the user can type 'y' or 'n' and press enter, that's an extra keypress that I find unnecessary.

I'm not aware of any confirmation popups where [y/N] would be preferable to [Y/n]. If we come across a confirmation popup where [y/N] makes more sense, I think a menu with two items would likely be better.

[jesseduffield]

Actually that might be a way to solve this problem: literally use a menu in place of a confirmation panel: but allow for menus to have prompt text at the top. We can have 'y' and 'n' be assigned to the yes and no menu items, and enter/escape will have the same effect as before.

[mark2185]

In confirmation boxes, you're able to confirm with either Enter or y.

That's no longer true since #2495 , now one can confirm only with Enter.

[jesseduffield]

Closing as we now only allow enter/esc for confirmation panels and so it's consistent (and we get more keybindings freed up for other things).