neovim/test/functional/lua/ui_spec.lua

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

134 lines
4.2 KiB
Lua
Raw Normal View History

local helpers = require('test.functional.helpers')(after_each)
local eq = helpers.eq
local exec_lua = helpers.exec_lua
local clear = helpers.clear
local feed = helpers.feed
local eval = helpers.eval
local poke_eventloop = helpers.poke_eventloop
describe('vim.ui', function()
before_each(function()
clear()
end)
describe('select', function()
it('can select an item', function()
local result = exec_lua[[
local items = {
{ name = 'Item 1' },
{ name = 'Item 2' },
}
local opts = {
format_item = function(entry)
return entry.name
end
}
local selected
local cb = function(item)
selected = item
end
-- inputlist would require input and block the test;
local choices
vim.fn.inputlist = function(x)
choices = x
return 1
end
vim.ui.select(items, opts, cb)
vim.wait(100, function() return selected ~= nil end)
return {selected, choices}
]]
eq({ name = 'Item 1' }, result[1])
eq({
'Select one of:',
'1: Item 1',
'2: Item 2',
}, result[2])
end)
end)
describe('input', function()
it('can input text', function()
local result = exec_lua[[
local opts = {
prompt = 'Input: ',
}
local input
local cb = function(item)
input = item
end
-- input would require input and block the test;
local prompt
vim.fn.input = function(opts)
prompt = opts.prompt
return "Inputted text"
end
vim.ui.input(opts, cb)
vim.wait(100, function() return input ~= nil end)
return {input, prompt}
]]
eq('Inputted text', result[1])
eq('Input: ', result[2])
end)
it('can input text on nil opt', function()
feed(':lua vim.ui.input(nil, function(input) result = input end)<cr>')
eq('', eval('v:errmsg'))
feed('Inputted text<cr>')
eq('Inputted text', exec_lua('return result'))
end)
it('can input text on {} opt', function()
feed(':lua vim.ui.input({}, function(input) result = input end)<cr>')
eq('', eval('v:errmsg'))
feed('abcdefg<cr>')
eq('abcdefg', exec_lua('return result'))
end)
it('can input empty text #18144', function()
feed(':lua vim.ui.input({}, function(input) result = input end)<cr>')
feed('<cr>')
eq('', exec_lua('return result'))
end)
it('can input empty text with cancelreturn opt #18144', function()
feed(':lua vim.ui.input({ cancelreturn = "CANCEL" }, function(input) result = input end)<cr>')
feed('<cr>')
eq('', exec_lua('return result'))
end)
it('can return nil when aborted with ESC #18144', function()
feed(':lua result = "on_confirm not called"<cr>')
feed(':lua vim.ui.input({}, function(input) result = input end)<cr>')
feed('Inputted Text<esc>')
-- Note: When `result == nil`, exec_lua('returns result') returns vim.NIL
eq(true, exec_lua('return (nil == result)'))
end)
it('can return opts.cacelreturn when aborted with ESC with cancelreturn opt #18144', function()
feed(':lua result = "on_confirm not called"<cr>')
feed(':lua vim.ui.input({ cancelreturn = "CANCEL" }, function(input) result = input end)<cr>')
feed('Inputted Text<esc>')
eq('CANCEL', exec_lua('return result'))
end)
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.
2022-11-12 07:57:35 -07:00
it('can return nil when interrupted with Ctrl-C #18144', function()
feed(':lua result = "on_confirm not called"<cr>')
feed(':lua vim.ui.input({}, function(input) result = input end)<cr>')
poke_eventloop() -- This is needed because Ctrl-C flushes input
feed('Inputted Text<c-c>')
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.
2022-11-12 07:57:35 -07:00
eq(true, exec_lua('return (nil == result)'))
end)
it('can return the identical object when an arbitrary opts.cancelreturn object is given', function()
feed(':lua fn = function() return 42 end<CR>')
eq(42, exec_lua('return fn()'))
feed(':lua vim.ui.input({ cancelreturn = fn }, function(input) result = input end)<cr>')
feed('cancel<esc>')
eq(true, exec_lua('return (result == fn)'))
eq(42, exec_lua('return result()'))
end)
end)
end)