fix: vim.ui.input always calls callback #21006

Followup to #20883
Related: #18144

This patch changes the behavior of the default `vim.ui.input` when the user
aborts with `<C-c>`. Currently, it produces an error message + stack and causes
`on_confirm` to not be called. With this patch, `<C-c>` will cause `on_confirm`
to be called with `nil`, the same behavior as when the user aborts with `<Esc>`.
I can think of three good reasons why the behavior should be this way:

1. Easier for the user to understand** It's not intuitive for there to be two
   ways to abort an input dialog that have _different_ outcomes. As a user,
   I would expect any action that cancels the input to leave me in the same
   state. As a plugin author, I see no value in having two possible outcomes for
   aborting the input. I have to handle both cases, but I can't think of
   a situation where I would want to treat one differently than the other.

2. Provides an API that can be overridden by other implementations** The current
   contract of "throw an error upon `<C-c>`" cannot be replicated by async
   implementations of `vim.ui.input`. If the callsite wants to handle the case
   of the user hitting `<C-c>` they need to use `pcall(vim.ui.input, ...)`,
   however an async implementation will instantly return and so there will be no
   way for it to produce the same error-throwing behavior when the user inputs
   `<C-c>`. This makes it impossible to be fully API-compatible with the
   built-in `vim.ui.input`.

3. Provides a useful guarantee to the callsite** As a plugin author, I want the
   guarantee that `on_confirm` will _always_ be called (only catastrophic errors
   should prevent this). If I am in the middle of some async thread of logic,
   I need some way to resume that logic after handing off control to
   `vim.ui.input`. The only way to handle the `<C-c>` case is with `pcall`,
   which as already mentioned, breaks down if you're using an alternative
   implementation.

0 files changed, 0 insertions, 0 deletions