| Commit message (Collapse) | Author | Age |
|
|
| |
also add metadata comment and update Lua code in syntax file
|
| |
|
|
|
|
|
|
|
| |
This aligns its behaviour better with `nvim_win_close`.
Note that `:hide` is actually incapable of closing the cmdwin, unlike `:close`
and `:quit`, so this is a bit of a difference in behaviour.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: As discussed on Matrix, there was some interest in having
`nvim_open_win` again be able to open floats in the cmdwin (e.g: displaying a
hover doc related to what's in the cmdwin). After #23228, this was disallowed.
Solution: Allow `nvim_open_win` in the cmdwin as long as `!enter` and
`buffer != curbuf` (the former can cause all sorts of issues, and the latter
can crash Nvim after closing cmdwin). Also allow `nvim_win_set_buf` in a similar
fashion.
Note that we're not *entirely* sure if this is 100% safe (cmdwin is a
global-state-using-main-loop-calling beast), but this seems to work OK..?
Also:
- Check the buffer argument of `nvim_open_win` earlier, and abort if it's
invalid (it used to still open a window in this case).
- Untranslate `e_cmdwin` errors in the API (other errors in the API are not
translated: although not detailed in the API contract yet, errors are
supposed to be stable).
|
|
|
|
|
|
|
| |
When signature is a bit long or there are too many tags, the tags appear
before the signature's line. Don't include the line with tags in the
previous function' docs.
Also fix lint warnings.
|
|
|
|
|
|
|
| |
Problem:
No LSP information for `vim.fn.*`
Solution:
Add meta file for `vim.fn.*`.
|
|
|
|
| |
`buf_notify` sends the notification to all clients of a buffer, calling
that inside a loop over clients multiplies the amount of notifications.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: No test for bad use of spaces in help files.
Solution: Add checks for use of spaces in help files. Ignore intentional
spaces. (Hirohito Higashi, closes vim/vim#11952)
https://github.com/vim/vim/commit/d950984489e50b12d87c85f0cce1d672c880aa23
Cherry-pick changes from patch 9.0.1604.
Co-authored-by: h-east <h.east.727@gmail.com>
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
Nvim LSP client always treats signature.documentation as markdown, even
if the server returns a plain string.
Per https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#signatureInformation
in a SignatureInformation response, the documentation field can be
either "string" or "MarkupContent".
Solution:
If signature.documentation is a string, treat it as "plaintext".
Closes #16563
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
Content that has codeblocks with different languages, results in
multiple calls to:
syntax include vim syntax/vim.vim
which raises error:
E403: syntax sync: line continuations pattern specified twice
Before ba8f19ebb67ca27d746f4b1cd902ab3d807eace3, this was avoided by
using pcall() to ignore the error.
Solution:
Restore the use of pcall() to ignore the error.
We plan to replace this logic with a treesitter approach, so this is
good enough for now.
Fix #24431
|
|
|
|
|
|
|
|
|
| |
* fix(lsp): replace @private with @nodoc for public client functions
To prevent lua-ls warnings in plugins which use the functions.
* fix(lsp): remove duplicate type annotations/class definitions
These annotations became duplicate with https://github.com/neovim/neovim/pull/23750
|
|
|
|
|
|
|
|
|
|
|
| |
Neovim already passed `data` element from published diagnostic to code action, but failed to announce it in client capabilities.
Here is the test that shows that `data` element is returned by `vim.lsp.diagnostic.get_line_diagnostics()`:
https://github.com/neovim/neovim/blob/f56c1848091bb64c63b5bc25ec74bcbd2f52bdde/test/functional/plugin/lsp/diagnostic_spec.lua#L103-L115
and then `get_line_diagnostics()` is used to construct the context for code action request:
https://github.com/neovim/neovim/blob/f56c1848091bb64c63b5bc25ec74bcbd2f52bdde/runtime/lua/vim/lsp/buf.lua#L742
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When adding `workspace/didChangeWorkspaceFolders` support to my [language server](https://github.com/elixir-tools/next-ls), I noticed that when neovim removes a workspace, it sends an empty table (which is serialized to an empty JSON array) for the value in the `added` field.
This does not follow the spec; the `added` table should just be empty.
The following error led me to this discovery. Note the payload includes `"added" => [[]]`:
```
22:46:48.476 [error] LSP Exited.
Last message received: handle_notification %{"jsonrpc" => "2.0", "method" => "workspace/didChangeWorkspaceFolders", "params" => %{"event" => %{"added" => [[]], "removed" => [%{"name" => "/Users/mitchell/src/gen_lsp", "uri" => "file:///Users/mitchell/src/gen_lsp"}]}}}
** (MatchError) no match of right hand side value: {:error, %{"params" => %{"event" => %{"added" => [error: "expected a map"]}}}}
(gen_lsp 0.4.0) lib/gen_lsp.ex:265: anonymous fn/4 in GenLSP.loop/3
(gen_lsp 0.4.0) lib/gen_lsp.ex:292: GenLSP.attempt/3
(stdlib 5.0.2) proc_lib.erl:241: :proc_lib.init_p_do_apply/3
```
|
|
|
|
|
| |
In the case you hit this warning in a buffer (like with C++ and clangd),
this message potentially fires over and over again making it difficult
to use the editor at all.
|
|
|
|
|
|
|
|
| |
Problem:
netrw may conflict with the Nvim default "gx" mapping.
Solution:
Initialize keymapping earlier by moving it to vim._init_default_mappings().
That also avoids needing to check maparg().
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
Fixes #24398
|
| |
|
|\
| |
| | |
fix(ui.open): some URLs fail on Windows
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
| |
Alphabetize LSP events, and make formatting consistent.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Also fixes https://github.com/neovim/neovim/issues/24369 by adding an
extra `vim.schedule` to ensure the `vim.fn.complete` call happens
outside of a luv callback
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* docs(lua): teach lua2dox how to table
* docs(lua): teach gen_vimdoc.py about local functions
No more need to mark local functions with @private
* docs(lua): mention @nodoc and @meta in dev-lua-doc
* fixup!
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
---------
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
|
| |
|
|
|
| |
Preserve last slash in windows' root drive directories
|
|\
| |
| | |
docs(lua): move some function docs to lua files
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem:
If clipboard job exits by signal, the exit code is >=128:
https://github.com/neovim/neovim/commit/939d9053bdf2f56286640c581eb4e2ff5a856540
xclip 0.13 often exits with code 143, which spams unhelpful messages:
clipboard: error invoking xclip: Waiting for selection requests,
Control-C to quit Waiting for selection request number 1
Solution:
Don't show a warning if the clipboard tool exit code is >=128.
Fixes: #7054
|
| |
| |
| |
| | |
Make |tui-modifyOtherKeys| and |tui-csiu| tags appear at a better place.
Also adapt the |<Tab>| help update from https://github.com/vim/vim/commit/dad4473f02e1fec86d43a2fc094536a4b27d3b25
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem:
Bash language server returns "hover" markdown content that starts with
a code fence and info string of `man` preceded by whitespace, which Nvim
does not render properly.
See https://github.com/bash-lsp/bash-language-server/blob/0ee73c53cebdc18311d4a4ad9367185ea4d98a03/server/src/server.ts#L821C15-L821C15
```typescript
function getMarkdownContent(documentation: string, language?: string): LSP.MarkupContent {
return {
value: language
? // eslint-disable-next-line prefer-template
['``` ' + language, documentation, '```'].join('\n')
: documentation,
kind: LSP.MarkupKind.Markdown,
}
}
```
For example,
```
``` man
NAME
git - the stupid content tracker
```
```
If I remove the white space, then it is properly formatted.
```
```man instead of ``` man
```
Per CommonMark Spec https://spec.commonmark.org/0.30/#info-string
whitespace is allowed before and after the `info string` which
identifies the language in a codeblock.
> The line with the opening code fence may optionally contain some text
> following the code fence; this is trimmed of leading and trailing
> spaces or tabs and called the [info
> string](https://spec.commonmark.org/0.30/#info-string). If the [info
> string](https://spec.commonmark.org/0.30/#info-string) comes after
> a backtick fence, it may not contain any backtick characters. (The
> reason for this restriction is that otherwise some inline code would
> be incorrectly interpreted as the beginning of a fenced code block.)
Solution:
Adjust stylize_markdown() to allow whitespace before codeblock info.
|
|/ |
|
|
|
| |
Related: https://github.com/neovim/neovim/issues/24252
|
|
|
| |
'hierarchicalWorkspaceSymbolSupport' is not part of the LSP Specification
|
| |
|
|
|
| |
Might help with discovery, given that there is no `keymap.get()`
|