aboutsummaryrefslogtreecommitdiff
path: root/runtime/lua/vim/ui.lua
diff options
context:
space:
mode:
authorSteven Arcangeli <506791+stevearc@users.noreply.github.com>2022-11-12 06:57:35 -0800
committerGitHub <noreply@github.com>2022-11-12 06:57:35 -0800
commitb3f781ba912b0d24896d85fc8434faaedfddfeb2 (patch)
tree6a5b82909bf788ed35fd502ed4b8b14e37253273 /runtime/lua/vim/ui.lua
parent3621c127a841b6aa5dbd12548b25f42534a91a26 (diff)
downloadrneovim-b3f781ba912b0d24896d85fc8434faaedfddfeb2.tar.gz
rneovim-b3f781ba912b0d24896d85fc8434faaedfddfeb2.tar.bz2
rneovim-b3f781ba912b0d24896d85fc8434faaedfddfeb2.zip
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.
Diffstat (limited to 'runtime/lua/vim/ui.lua')
-rw-r--r--runtime/lua/vim/ui.lua4
1 files changed, 2 insertions, 2 deletions
diff --git a/runtime/lua/vim/ui.lua b/runtime/lua/vim/ui.lua
index d9a3963afc..97dccd83ab 100644
--- a/runtime/lua/vim/ui.lua
+++ b/runtime/lua/vim/ui.lua
@@ -95,8 +95,8 @@ function M.input(opts, on_confirm)
local _canceled = vim.NIL
opts = vim.tbl_extend('keep', opts, { cancelreturn = _canceled })
- local input = vim.fn.input(opts)
- if input == _canceled then
+ local ok, input = pcall(vim.fn.input, opts)
+ if not ok or input == _canceled then
on_confirm(nil)
else
on_confirm(input)