<feed xmlns='http://www.w3.org/2005/Atom'>
<title>rneovim.git/test/functional/lua/ui_spec.lua, branch usermarks</title>
<subtitle>Neovim fork with Rahm's personal hacks.</subtitle>
<link rel='alternate' type='text/html' href='http://git.josher.dev/rneovim.git/'/>
<entry>
<title>test(lua/ui_spec): fix Ctrl-C test flakiness (#21039)</title>
<updated>2022-11-13T00:16:06+00:00</updated>
<author>
<name>zeertzjq</name>
<email>zeertzjq@outlook.com</email>
</author>
<published>2022-11-13T00:16:06+00:00</published>
<link rel='alternate' type='text/html' href='http://git.josher.dev/rneovim.git/commit/?id=e7ba5ba3cd8e426d07a8359a3d85a62b095faf61'/>
<id>e7ba5ba3cd8e426d07a8359a3d85a62b095faf61</id>
<content type='text'>
Prevent Ctrl-C from flushing the command that starts the prompt.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Prevent Ctrl-C from flushing the command that starts the prompt.</pre>
</div>
</content>
</entry>
<entry>
<title>fix: vim.ui.input always calls callback #21006</title>
<updated>2022-11-12T14:57:35+00:00</updated>
<author>
<name>Steven Arcangeli</name>
<email>506791+stevearc@users.noreply.github.com</email>
</author>
<published>2022-11-12T14:57:35+00:00</published>
<link rel='alternate' type='text/html' href='http://git.josher.dev/rneovim.git/commit/?id=b3f781ba912b0d24896d85fc8434faaedfddfeb2'/>
<id>b3f781ba912b0d24896d85fc8434faaedfddfeb2</id>
<content type='text'>
Followup to #20883
Related: #18144

This patch changes the behavior of the default `vim.ui.input` when the user
aborts with `&lt;C-c&gt;`. Currently, it produces an error message + stack and causes
`on_confirm` to not be called. With this patch, `&lt;C-c&gt;` will cause `on_confirm`
to be called with `nil`, the same behavior as when the user aborts with `&lt;Esc&gt;`.
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 `&lt;C-c&gt;`" cannot be replicated by async
   implementations of `vim.ui.input`. If the callsite wants to handle the case
   of the user hitting `&lt;C-c&gt;` 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
   `&lt;C-c&gt;`. 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 `&lt;C-c&gt;` case is with `pcall`,
   which as already mentioned, breaks down if you're using an alternative
   implementation.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Followup to #20883
Related: #18144

This patch changes the behavior of the default `vim.ui.input` when the user
aborts with `&lt;C-c&gt;`. Currently, it produces an error message + stack and causes
`on_confirm` to not be called. With this patch, `&lt;C-c&gt;` will cause `on_confirm`
to be called with `nil`, the same behavior as when the user aborts with `&lt;Esc&gt;`.
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 `&lt;C-c&gt;`" cannot be replicated by async
   implementations of `vim.ui.input`. If the callsite wants to handle the case
   of the user hitting `&lt;C-c&gt;` 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
   `&lt;C-c&gt;`. 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 `&lt;C-c&gt;` case is with `pcall`,
   which as already mentioned, breaks down if you're using an alternative
   implementation.</pre>
</div>
</content>
</entry>
<entry>
<title>fix(vim.ui.input): return empty string when inputs nothing (#20883)</title>
<updated>2022-11-08T00:15:15+00:00</updated>
<author>
<name>Jongwook Choi</name>
<email>wookayin@gmail.com</email>
</author>
<published>2022-11-08T00:15:15+00:00</published>
<link rel='alternate' type='text/html' href='http://git.josher.dev/rneovim.git/commit/?id=59ff4691f67fc1ddd3d1b7240a2f2eb095e58281'/>
<id>59ff4691f67fc1ddd3d1b7240a2f2eb095e58281</id>
<content type='text'>
fix(vim.ui.input): return empty string when inputs nothing

The previous behavior of `vim.ui.input()` when typing &lt;CR&gt; 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.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
fix(vim.ui.input): return empty string when inputs nothing

The previous behavior of `vim.ui.input()` when typing &lt;CR&gt; 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.</pre>
</div>
</content>
</entry>
<entry>
<title>fix(vim.ui.input): accept nil or empty "opts"  #19109</title>
<updated>2022-06-28T09:53:15+00:00</updated>
<author>
<name>0x74696d6d79</name>
<email>34635512+tzx@users.noreply.github.com</email>
</author>
<published>2022-06-28T09:53:15+00:00</published>
<link rel='alternate' type='text/html' href='http://git.josher.dev/rneovim.git/commit/?id=ee6b21e8430ea810ba2e3e9163b941386a2e1d65'/>
<id>ee6b21e8430ea810ba2e3e9163b941386a2e1d65</id>
<content type='text'>
Fix #18143</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix #18143</pre>
</div>
</content>
</entry>
<entry>
<title>feat(ui): add vim.ui.input and use in lsp rename (#15959)</title>
<updated>2021-11-07T15:13:53+00:00</updated>
<author>
<name>Sebastian Lyng Johansen</name>
<email>seblyng98@gmail.com</email>
</author>
<published>2021-11-07T15:13:53+00:00</published>
<link rel='alternate' type='text/html' href='http://git.josher.dev/rneovim.git/commit/?id=16d4af6d2f549709aa55510f5ae52238c5cadb9c'/>
<id>16d4af6d2f549709aa55510f5ae52238c5cadb9c</id>
<content type='text'>
* vim.ui.input is an overridable function that prompts for user input
* take an opts table and the `on_confirm` callback, see `:help vim.ui.input` for more details
* defaults to a wrapper around vim.fn.input(opts)
* switches the built-in client's rename handler to use vim.ui.input by default</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* vim.ui.input is an overridable function that prompts for user input
* take an opts table and the `on_confirm` callback, see `:help vim.ui.input` for more details
* defaults to a wrapper around vim.fn.input(opts)
* switches the built-in client's rename handler to use vim.ui.input by default</pre>
</div>
</content>
</entry>
<entry>
<title>fix(ui): s/format_entry/format_item to match docs (#15819)</title>
<updated>2021-09-27T23:12:03+00:00</updated>
<author>
<name>Mathias Fußenegger</name>
<email>mfussenegger@users.noreply.github.com</email>
</author>
<published>2021-09-27T23:12:03+00:00</published>
<link rel='alternate' type='text/html' href='http://git.josher.dev/rneovim.git/commit/?id=9ca7b6b71a1e98ff6a76270d165fc8f07763a0c3'/>
<id>9ca7b6b71a1e98ff6a76270d165fc8f07763a0c3</id>
<content type='text'>
Follow up to https://github.com/neovim/neovim/pull/15771</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Follow up to https://github.com/neovim/neovim/pull/15771</pre>
</div>
</content>
</entry>
<entry>
<title>feat(ui): add vim.ui.select and use in code actions (#15771)</title>
<updated>2021-09-27T19:57:28+00:00</updated>
<author>
<name>Mathias Fußenegger</name>
<email>mfussenegger@users.noreply.github.com</email>
</author>
<published>2021-09-27T19:57:28+00:00</published>
<link rel='alternate' type='text/html' href='http://git.josher.dev/rneovim.git/commit/?id=63fde086d9e7936b21c51e145253ec69820b2112'/>
<id>63fde086d9e7936b21c51e145253ec69820b2112</id>
<content type='text'>
Continuation of https://github.com/neovim/neovim/pull/15202

A plugin like telescope could override it with a fancy implementation
and then users would get the telescope-ui within each plugin that
utilizes the vim.ui.select function.

There are some plugins which override the `textDocument/codeAction`
handler solely to provide a different UI. With custom client commands and
soon codeAction resolve support, it becomes more difficult to implement
the handler right - so having a dedicated way to override the picking
function will be useful.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Continuation of https://github.com/neovim/neovim/pull/15202

A plugin like telescope could override it with a fancy implementation
and then users would get the telescope-ui within each plugin that
utilizes the vim.ui.select function.

There are some plugins which override the `textDocument/codeAction`
handler solely to provide a different UI. With custom client commands and
soon codeAction resolve support, it becomes more difficult to implement
the handler right - so having a dedicated way to override the picking
function will be useful.</pre>
</div>
</content>
</entry>
</feed>
