| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
Obviously not all vis users are running Linux therefore vis-lspc uses
sh -c "echo $PPID" as fallback if /proc/self/stat is not available.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
New algorithm:
1. check if the cursor is on a word which is a prefix of the completion
2. if not try to decrement the position because it is common than the
cursor is behind the token to complete "fooba┃"
3. if found a match in 1. or 2. delete it
4. insert the new text at the current pos or the start of the deleted token
Hopefully this is good enough to work in all possible corner cases
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Previously we managed running language servers by language but this
is not practical since one language server can serve multiple languages.
Clangd for example can deal with cpp and c code which frequently are
used together in the same code base.
Therefore we now manage running language servers by name and map
syntax to language server names and to LSP languageIds as well.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This is the first minor release of vis-lspc.
It is now in a state that it satisfies all use cases I currently have
for a LSP client implementation.
This means I will not implement new features or change existing code
as frequent as before.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* Add support for user choices by piping the available choices through
lspc.menu_cmd which must be a dmenu|vis-menu|fzf like tool.
* Mention all commands and options in the README
* Add support for textDocument/references
* Support opening new location in a horizonatl or vertical split
* Internal refactoring
* Group binding, vis command and event code
* Return error messages and use vis:info only in vis commands
* Fix a bug on unexpected server termination
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We currently have no good way of detecting changes in a file,
therefore we send the whole file content in a textDocument/didChange
notification each time we want something from the language server.
Consequences from this design:
* diagnostics are not up to date till the client calls a server method
* The server may need longer for its answer when it it informed about
changes immediately before the client requests its service
* We pass unnecessary much data between server and client which may be
unpractical for huge files
|
| |
|
