diff options
author | Steven Arcangeli <506791+stevearc@users.noreply.github.com> | 2022-11-12 06:57:35 -0800 |
---|---|---|
committer | GitHub <noreply@github.com> | 2022-11-12 06:57:35 -0800 |
commit | b3f781ba912b0d24896d85fc8434faaedfddfeb2 (patch) | |
tree | 6a5b82909bf788ed35fd502ed4b8b14e37253273 /test/functional/lua/ui_spec.lua | |
parent | 3621c127a841b6aa5dbd12548b25f42534a91a26 (diff) | |
download | rneovim-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 'test/functional/lua/ui_spec.lua')
-rw-r--r-- | test/functional/lua/ui_spec.lua | 6 |
1 files changed, 2 insertions, 4 deletions
diff --git a/test/functional/lua/ui_spec.lua b/test/functional/lua/ui_spec.lua index 8f9d8e0f72..c34d947b8b 100644 --- a/test/functional/lua/ui_spec.lua +++ b/test/functional/lua/ui_spec.lua @@ -111,13 +111,11 @@ describe('vim.ui', function() eq('CANCEL', exec_lua('return result')) end) - it('does not call on_confirm when interrupted with Ctrl-C #18144', function() + it('can return nil when interrupted with Ctrl-C #18144', function() feed(':lua result = "on_confirm not called"<cr>') - eq('on_confirm not called', exec_lua('return result')) feed(':lua vim.ui.input({}, function(input) result = input end)<cr>') feed('Inputted Text<c-c>') - -- Ctrl-C would make vim.ui.input() throw, so `result = input` won't be executed - eq('on_confirm not called', exec_lua('return result')) + eq(true, exec_lua('return (nil == result)')) end) it('can return the identical object when an arbitrary opts.cancelreturn object is given', function() |