neovim/runtime/lua/vim/ui.lua

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

107 lines
3.5 KiB
Lua
Raw Normal View History

local M = {}
--- Prompts the user to pick a single item from a collection of entries
---
---@param items table Arbitrary items
---@param opts table Additional options
--- - prompt (string|nil)
--- Text of the prompt. Defaults to `Select one of:`
--- - format_item (function item -> text)
--- Function to format an
--- individual item from `items`. Defaults to `tostring`.
--- - kind (string|nil)
--- Arbitrary hint string indicating the item shape.
--- Plugins reimplementing `vim.ui.select` may wish to
--- use this to infer the structure or semantics of
--- `items`, or the context in which select() was called.
---@param on_choice function ((item|nil, idx|nil) -> ())
--- Called once the user made a choice.
--- `idx` is the 1-based index of `item` within `items`.
--- `nil` if the user aborted the dialog.
---
---
--- Example:
--- <pre>lua
--- vim.ui.select({ 'tabs', 'spaces' }, {
--- prompt = 'Select tabs or spaces:',
--- format_item = function(item)
--- return "I'd like to choose " .. item
--- end,
--- }, function(choice)
--- if choice == 'spaces' then
--- vim.o.expandtab = true
--- else
--- vim.o.expandtab = false
--- end
--- end)
--- </pre>
function M.select(items, opts, on_choice)
vim.validate({
items = { items, 'table', false },
on_choice = { on_choice, 'function', false },
})
opts = opts or {}
local choices = { opts.prompt or 'Select one of:' }
local format_item = opts.format_item or tostring
for i, item in pairs(items) do
table.insert(choices, string.format('%d: %s', i, format_item(item)))
end
local choice = vim.fn.inputlist(choices)
if choice < 1 or choice > #items then
on_choice(nil, nil)
else
on_choice(items[choice], choice)
end
end
--- Prompts the user for input
---
---@param opts table Additional options. See |input()|
--- - prompt (string|nil)
--- Text of the prompt
--- - default (string|nil)
--- Default reply to the input
--- - completion (string|nil)
--- Specifies type of completion supported
--- for input. Supported types are the same
--- that can be supplied to a user-defined
--- command using the "-complete=" argument.
--- See |:command-completion|
--- - highlight (function)
--- Function that will be used for highlighting
--- user inputs.
---@param on_confirm function ((input|nil) -> ())
--- Called once the user confirms or abort the input.
--- `input` is what the user typed (it might be
--- an empty string if nothing was entered), or
--- `nil` if the user aborted the dialog.
---
--- Example:
--- <pre>lua
--- vim.ui.input({ prompt = 'Enter value for shiftwidth: ' }, function(input)
--- vim.o.shiftwidth = tonumber(input)
--- end)
--- </pre>
function M.input(opts, on_confirm)
vim.validate({
on_confirm = { on_confirm, 'function', false },
})
opts = (opts and not vim.tbl_isempty(opts)) and opts or vim.empty_dict()
-- Note that vim.fn.input({}) returns an empty string when cancelled.
-- vim.ui.input() should distinguish aborting from entering an empty string.
local _canceled = vim.NIL
opts = vim.tbl_extend('keep', opts, { cancelreturn = _canceled })
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
local ok, input = pcall(vim.fn.input, opts)
if not ok or input == _canceled then
on_confirm(nil)
else
on_confirm(input)
end
end
return M