Problem:
On Windows, `explorer.exe` fails to open some URLs, for example:

    :lua vim.ui.open('https://devdocs.io/#q=lua%20lua_call')

https://github.com/neovim/neovim/pull/23401#issuecomment-1641015704

Solution:
Use rundll32 instead.

Problem:
Showing an error via vim.notify() makes it awkward for callers such as
lsp/handlers.lua to avoid showing redundant errors.

Solution:
Return the message instead of showing it. Let the caller decide whether
and when to show the message.

---
Rejected experiment: move vim.ui.open() to vim.env.open()

Problem:
`vim.ui` is where user-interface "providers" live, which can be
overridden. It would also be useful to have a "providers" namespace for
platform-specific features such as "open", clipboard, python, and the other
providers listed in `:help providers`. We could overload `vim.ui` to
serve that purpose as the single "providers" namespace, but
`vim.ui.nodejs()` for example seems awkward.

Solution:
`vim.env` currently has too narrow of a purpose. Overload it to also be
a namespace for `vim.env.open`.

diff --git a/runtime/lua/vim/_meta.lua b/runtime/lua/vim/_meta.lua
index 913f1fe20348..17d05ff37595 100644
--- a/runtime/lua/vim/_meta.lua
+++ b/runtime/lua/vim/_meta.lua
@@ -37,8 +37,28 @@ local options_info = setmetatable({}, {
   end,
 })

-vim.env = setmetatable({}, {
-  __index = function(_, k)
+vim.env = setmetatable({
+  open = setmetatable({}, {
+      __call = function(_, uri)
+        print('xxxxx'..uri)
+        return true
+      end,
+      __tostring = function()
+        local v = vim.fn.getenv('open')
+        if v == vim.NIL then
+          return nil
+        end
+        return v
+      end,
+    })
+  },
+  {
+  __index = function(t, k, ...)
+    if k == 'open' then
+      error()
+      -- vim.print({...})
+      -- return rawget(t, k)
+    end
     local v = vim.fn.getenv(k)
     if v == vim.NIL then
       return nil

Co-authored-by: Mathias Fußenegger <mfussenegger@users.noreply.github.com>
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Co-authored-by: ii14 <59243201+ii14@users.noreply.github.com>

close #21063

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.

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.