The `callHierarchy` function should warn the user when
`textDocument/prepareCallHierarchy` didn't resolve an entity and
return, rather than calling the `callHierarchy/{incoming,outgoing}Calls`
method with an empty object - which is encoded as an empty list (which
doesn't respect language server specification for the
`callHierarchy/incomingCalls` call).
- Added `@inlinedoc` so single use Lua types can be inlined into the
functions docs. E.g.
```lua
--- @class myopts
--- @inlinedoc
---
--- Documentation for some field
--- @field somefield integer
--- @param opts myOpts
function foo(opts)
end
```
Will be rendered as
```
foo(opts)
Parameters:
- {opts} (table) Object with the fields:
- somefield (integer) Documentation
for some field
```
- Marked many classes with with `@nodoc` or `(private)`.
We can eventually introduce these when we want to.
Problem:
The documentation flow (`gen_vimdoc.py`) has several issues:
- it's not very versatile
- depends on doxygen
- doesn't work well with Lua code as it requires an awkward filter script to convert it into pseudo-C.
- The intermediate XML files and filters makes it too much like a rube goldberg machine.
Solution:
Re-implement the flow using Lua, LPEG and treesitter.
- `gen_vimdoc.py` is now replaced with `gen_vimdoc.lua` and replicates a portion of the logic.
- `lua2dox.lua` is gone!
- No more XML files.
- Doxygen is now longer used and instead we now use:
- LPEG for comment parsing (see `scripts/luacats_grammar.lua` and `scripts/cdoc_grammar.lua`).
- LPEG for C parsing (see `scripts/cdoc_parser.lua`)
- Lua patterns for Lua parsing (see `scripts/luacats_parser.lua`).
- Treesitter for Markdown parsing (see `scripts/text_utils.lua`).
- The generated `runtime/doc/*.mpack` files have been removed.
- `scripts/gen_eval_files.lua` now instead uses `scripts/cdoc_parser.lua` directly.
- Text wrapping is implemented in `scripts/text_utils.lua` and appears to produce more consistent results (the main contributer to the diff of this change).
Problem:
The LSP client code is implemented as a complicated closure-class
(class defined in a single function).
Solution:
Move LSP client code to a more conventional Lua class and move to a
separate file.
`code_action` used the same parameters for all clients, which led to the
following warning and incorrect start/end column locations if using
clients with mixed encodings:
warning: multiple different client offset_encodings detected for
buffer, this is not supported yet
Problem: Currently there is no way of customizing behavior of
`declaration`, `definition`, `typeDefinition`, and `implementation`
methods in `vim.lsp.buf` when LSP server returns `Location`. Instead,
cursor jumps to that location directly.
Solution: Normalize LSP response to be `Location[]` for those four cases.
The haskell-language-server supports resolve only for a subset of code
actions. For many code actions trying to resolve the `edit` property
results in an error, but the unresolved action already contains a
command that can be executed without issue.
The protocol specification is unfortunately a bit vague about this,
and what the haskell-language-server does seems to be valid.
Example:
newtype Dummy = Dummy Int
instance Num Dummy where
Triggering code actions on "Num Dummy" and choosing "Add placeholders
for all missing methods" resulted in:
-32601: No plugin enabled for SMethod_CodeActionResolve, potentially available: explicit-fields, importLens, hlint, overloaded-record-dot
With this change it will insert the missing methods:
instance Num Dummy where
(+) = _
(-) = _
(*) = _
negate = _
abs = _
signum = _
fromInteger = _
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
```
* 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>
Problem: in #24046 the signature of buf.clear_references() changed, which
indirectly breaks callers that were passing "ignored" args.
Solution: because util.buf_clear_references() already defaulted to "current buffer",
the change to buf.clear_references() isn't actually needed, so just revert it.
- fix lint / analysis warnings
- locations_to_items(): get default offset_encoding from active client
- character_offset(): get default offset_encoding from active client
Enforce consistent terminology (defined in
`gen_help_html.lua:spell_dict`) for common misspellings.
This does not spellcheck English in general (perhaps a future TODO,
though it may be noisy).
Add automatic refresh and a public interface on top of #23736
* add on_reload, on_detach handlers in `enable()` buf_attach, and
LspDetach autocommand in case of manual detach
* unify `__buffers` and `hint_cache_by_buf`
* use callback bufnr in `on_lines` callback, bufstate: remove __index override
* move user-facing functions into vim.lsp.buf, unify enable/disable/toggle
Closes#18086
Previously, filtering code actions with the "only" option failed
if the code action kind contained special Lua pattern chars such as "-"
(e.g. the ocaml language server supports a "type-annotate" code action).
Solution: use string comparison instead of string.find
- `client.dynamic_capabilities` is an object that tracks client register/unregister
- `client.supports_method` will additionally check if a dynamic capability supports the method, taking document filters into account. But only if the client enabled `dynamicRegistration` for the capability
- updated the default client capabilities to include dynamicRegistration for:
- formatting
- rangeFormatting
- hover
- codeAction
- hover
- rename
`vim.lsp.buf.format()` silently did nothing if no servers supported
`textDocument/rangeFormatting` when formatting with a range.
Issue found by `@hwrd:matrix.org` in the Matrix chat.
