| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The two new hooks allow to execute user code after certain events.
They are called with the language server table as first argument.
* initialized_hook is called after the initialized notification
was sent.
* file_open_hook is called after sending a textDocument/didOpen
notification.
|
| |
|
|
|
|
|
|
| |
Including methods in the language server table allows them to be used
outside of vis-lspc.
Additionally, I think this makes more sense to use them as methods
with the ls:method(...) syntax instead of calling them as ls_method(ls, ...).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This allows us to support opening a single file in multiple
language server instances.
This can be useful when combining for example a latex and a language
tool language server.
|
| |
|
|
|
| |
Replace the hacky style_lineno code with the new vis:style_pos
API probably included in upcoming vis v0.9.
|
| |
|
|
|
|
|
|
|
| |
The two options are either using vis:message (the default) which will
keep all messages in the vis message buffer and include a header line to
distinguish the different messages.
The second option is using open and presenting messages in a separate
window supporting syntax highlighting.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
restore the primary cursor position after a workspaceEdit
See merge request muhq/vis-lspc!47
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The last commit introduces support for highlighting empty selections
by properly calculating their vis ranges.
However File:content does return an empty string for empty ranges
and we can not check whether the diagnostic still applies to the same
position.
This is fixed by faking a one character range when receiving an
empty one.
Doing so we get a valid one-character content we can compare and
still have proper highlighting because we unconditionally decrement
the range end in highlight_diagnostics.
Fixes: 7099e56062861fc8dbb143e78447cce6bf886a97
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some language servers report diagnostics with empty ranges, start and
end are at the same line and character, which currently results in
no highlighting at all.
Since the end of a LSP range is exclusive we always subtract 1 from
it which results in invalid ranges when the server has sent an empty one.
Introduce a check to fix this special case.
`textDocument/publishDiagnostics` doesn't always have a `code` field,
resulting in `diagnostic.code` being nil and so it is replaced with
`diagnostic` in those cases.
|
| | |
|
| |
|
|
|
| |
Since the diagnostics table is created when we open the file
it will always be ~= nil.
|
| | |
|
| |
|
|
|
|
| |
This is implemented by the two new commands:
* lspc-next-diagnostics - jump to the next available diagnostic
* lspc-prev-diagnostics - jump to the previous available diagnostic
|
| |
|
|
|
|
|
|
| |
Range highlighting used the vis_range and line highlighting the LSP
range. Do not touch old code you no longer understand because you think
you are apparently smarter than your past self!
Fixes: efd5262f2c45d3289e482b1091d3c1d44cf67a42
|
| |
|
|
| |
Since vis 0.9 the options are exposed via the vis.options table.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
We do not support workspaceEdit.documentChanges but some LSP servers
do not respect our capabilities and send them anyways.
Try to optimistically convert simple documentChanges to plain changes.
We only support simple TextDocumentEdit[].
|
| |
|
|
|
|
|
|
|
|
|
| |
The method textDocument/formatting is allowed to return null/nil which
was directly passed to vis_apply_textEdits causing an exception
when trying to iterate the textEdits table.
Only pass the result of textDocument/formatting to vis_apply_textEdits
if there is an actual result.
Fixes: e83950a7149f364b653395cdd4d9446875a7f469
|
| |
|
|
|
| |
If the result is MarkedString[] the table must have a length > 0,
because all returned object types are represented as lua tables.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This should be wired up to code that's in a pull request in the vis
repository for the default options. This PR does not yet expose
`expandtab`.
Referenced PR: https://github.com/martanne/vis/pull/717
|
| |
|
|
|
|
|
| |
This is tested with the Rust language server and the Lua one. Moving
the cursor to the correct position afterwards works with Rust, but not
with Lua. Being smarter about the ranges is probably necessary for Lua
and might make other ones more robust.
|
| | |
|
| | |
|
| |
|
|
|
| |
When using vis_open_doc_pos, don't reopen the file if the path of the
opened file and the doc_pos match.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Currently if a method call result causing the editor to jump to a new
location is received from the language server we change the current
window ('vis.win').
However this behavior is strange if the user has already switch window
the message window was opened.
Remember the window where the jump was requested and execute it in
the original window.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We can not only use the fact that we have a method call inflight with
the observed id. Because the language server may has called a method
on use with the same id.
Therefore we have to also check if the incoming message contains
a method field.
method + id -> method call
id -> method response
method -> notification
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Send language server settings after initialization via a
workspace/didChangeConfiguration notification.
Implement a workspace/configuration handler using the values stored
in the language server settings.
Send the init_options as initializationOptions in the initialize
parameters.
|
| | |
|