From 59ff4691f67fc1ddd3d1b7240a2f2eb095e58281 Mon Sep 17 00:00:00 2001
From: Jongwook Choi <wookayin@gmail.com>
Date: Mon, 7 Nov 2022 19:15:15 -0500
Subject: fix(vim.ui.input): return empty string when inputs nothing (#20883)

fix(vim.ui.input): return empty string when inputs nothing

The previous behavior of `vim.ui.input()` when typing <CR> with
no text input (with an intention of having the empty string as input)
was to execute `on_confirm(nil)`, conflicting with its documentation.

Inputting an empty string should now correctly execute `on_confirm('')`.
This should be clearly distinguished from cancelling or aborting the
input UI, in which case `on_confirm(nil)` is executed as before.
---
 runtime/lua/vim/ui.lua | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

(limited to 'runtime/lua/vim/ui.lua')

diff --git a/runtime/lua/vim/ui.lua b/runtime/lua/vim/ui.lua
index 6f1ce3089d..d9a3963afc 100644
--- a/runtime/lua/vim/ui.lua
+++ b/runtime/lua/vim/ui.lua
@@ -73,7 +73,8 @@ end
 ---               user inputs.
 ---@param on_confirm function ((input|nil) -> ())
 ---               Called once the user confirms or abort the input.
----               `input` is what the user typed.
+---               `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:
@@ -88,11 +89,17 @@ function M.input(opts, on_confirm)
   })
 
   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 })
+
   local input = vim.fn.input(opts)
-  if #input > 0 then
-    on_confirm(input)
-  else
+  if input == _canceled then
     on_confirm(nil)
+  else
+    on_confirm(input)
   end
 end
 
-- 
cgit 


From b3f781ba912b0d24896d85fc8434faaedfddfeb2 Mon Sep 17 00:00:00 2001
From: Steven Arcangeli <506791+stevearc@users.noreply.github.com>
Date: Sat, 12 Nov 2022 06:57:35 -0800
Subject: 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.
---
 runtime/lua/vim/ui.lua | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

(limited to 'runtime/lua/vim/ui.lua')

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)
-- 
cgit 


From 0b05bd87c04f9cde5c84a062453619349e370795 Mon Sep 17 00:00:00 2001
From: Christian Clason <c.clason@uni-graz.at>
Date: Wed, 23 Nov 2022 12:31:49 +0100
Subject: docs(gen): support language annotation in docstrings

---
 runtime/lua/vim/ui.lua | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

(limited to 'runtime/lua/vim/ui.lua')

diff --git a/runtime/lua/vim/ui.lua b/runtime/lua/vim/ui.lua
index 97dccd83ab..8f5be15221 100644
--- a/runtime/lua/vim/ui.lua
+++ b/runtime/lua/vim/ui.lua
@@ -21,7 +21,7 @@ local M = {}
 ---
 ---
 --- Example:
---- <pre>
+--- <pre>lua
 --- vim.ui.select({ 'tabs', 'spaces' }, {
 ---     prompt = 'Select tabs or spaces:',
 ---     format_item = function(item)
@@ -78,7 +78,7 @@ end
 ---               `nil` if the user aborted the dialog.
 ---
 --- Example:
---- <pre>
+--- <pre>lua
 --- vim.ui.input({ prompt = 'Enter value for shiftwidth: ' }, function(input)
 ---     vim.o.shiftwidth = tonumber(input)
 --- end)
-- 
cgit