| Age | Commit message (Collapse) | Author | Files |
|---|
|
|
|
gen_vimdoc.lua: In prepare for the upcoming release, comment-out the
"Experimental" warning for prerelease features.
|
|
|
|
Close #37630
Close #37682
Close #37762
Close #37785
Co-authored-by: Daniel Schmitt <d.schmitt@lansoftware.de>
Co-authored-by: Duane Hilton <duane9@gmail.com>
Co-authored-by: NeOzay <colpaert.benoit@gmail.com>
Co-authored-by: Yi Ming <ofseed@foxmail.com>
Co-authored-by: "Justin M. Keyes" <justinkz@gmail.com>
|
|
fix(help): only set url for nvim-owned tags
Problem:
1. gx on |nonexistingtag| opens
https://neovim.io/doc/user/helptag.html?nonexistingtag.
2. b:undo_ftplugin doesn't remove url extmarks.
Solution:
1. Check if the tag is defined in a help file in $VIMRUNTIME.
2. Solution: clear namespace for buffer in b:undo_ftplugin.
|
|
Problem:
`gx` does not work on tags in help buffers to open the documentation of that tag in the browser.
Solution:
Get the `optionlink`, `taglink` and `tag` TS nodes and set extmark "url" property.
`gx` then discovers the extmark "url" and opens it.
|
|
|
|
|
|
reverts e0d92b9cc20b58179599f53dfa74ca821935a539 #28502
Problem:
`vim.ui.open()` has a `pcall()` like signature, under the assumption
that this is the Lua idiom for returning result-or-error. However, the
`result|nil, errmsg|nil` pattern:
- has precedent in:
- `io.open`
- `vim.uv` (`:help luv-error-handling`)
- has these advantages:
- Can be used with `assert()`:
```
local result, err = assert(foobar())
```
- Allows LuaLS to infer the type of `result`:
```
local result, err = foobar()
if err then
...
elseif result then
...
end
```
Solution:
- Revert to the `result|nil, errmsg|nil` pattern.
- Document the pattern in our guidelines.
|
|
Problem:
`vim.ui.open` unnecessarily invents a different success/failure
convention. Its return type was changed in 57adf8c6e01d, so we might as
well change it to have a more conventional form.
Solution:
Change the signature to use the `pcall` convention of `status, result`.
|
|
Specifically, functions that are run in the context of the test runner
are put in module `test/testutil.lua` while the functions that are run
in the context of the test session are put in
`test/functional/testnvim.lua`.
Closes https://github.com/neovim/neovim/issues/27004.
|
|
Problem:
explorer.exe is unreliable on WSL.
Solution:
Try wslview before explorer.exe.
fix #28410
|
|
Problem:
vim.ui.open "locks up" Nvim if the spawned process does not terminate. #27986
Solution:
- Change `vim.ui.open()`:
- Do not call `wait()`.
- Return a `SystemObj`. The caller can decide if it wants to `wait()`.
- Change `gx` to `wait()` only a short time.
- Allows `gx` to show a message if the command fails, without the
risk of waiting forever.
|
|
|
|
Work on https://github.com/neovim/neovim/issues/27004.
|
|
Problem:
`vim.ui.open` uses `wslview`, which is slow and require a package from external PPA:
https://wslutiliti.es/wslu/install.html#ubuntu
Solution:
Use `explorer.exe` instead. WSL supports it by default:
https://learn.microsoft.com/en-us/windows/wsl/filesystems#view-your-current-directory-in-windows-file-explorer
|
|
|
|
Problem:
On Windows, `rundll32` exits zero (success) even when given
a non-existent file.
Solution:
Mock vim.system() on Windows to force a "failure" case.
|
|
Fix hang after running vim.system() with sanitizers.
|
|
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
|
|
Prevent Ctrl-C from flushing the command that starts the prompt.
|
|
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.
|
|
Fix #18143
|
|
* 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
|
|
Follow up to https://github.com/neovim/neovim/pull/15771
|
|
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.
|
