kakoune-lsp / kakoune-lsp Goto Github PK
View Code? Open in Web Editor NEWKakoune Language Server Protocol Client
License: The Unlicense
Kakoune Language Server Protocol Client
License: The Unlicense
At the moment kak-lsp tries to read config from ~/.config/kak-lsp
(which should be improved as well i.e. to respect XDG_CONFIG_HOME). If it fails then it tries to read config from the directory where binary is located. This is a workaround to have kak-lsp working without extra manual steps after installation from homebrew, because the latter doesn't allow writing to user's directory during installation.
This behaviour is not very nice because it demands putting configuration and binary in the same directory which violates wide-spread convention. Embedding default config is easy and clear solution for zero-conf installation.
Sometimes particular language server crashes and kak-lsp starts shouting into the void for server's route. It should restart that language server instead.
Group locations by file and scan each file once.
In many cases this autocompletion is useless and prevents from immediate tab insertion.
And generate relative paths.
Some of language servers take a long time to initialize. Most of them report progress and/or ready event. We need to indicate their progress somehow to prevent confusion like "why does 'go to definition' not work? is it broken?" during initialization.
I need help to understand what is the best way in Kakoune to communicate such kind of information. It should be non-intrusive and discoverable at the same time. Should it be echo
or info
(the former could be easily missed and the latter feels too noisy)? Ideal would be to show in status line (like echo
) but persistent and update according to language server status change.
kak-lsp grows organically and requires gardening phase to keep it in shape and prevent from turning into bush.
Refactor should be done after #7 and include:
Context
now plays role of mutable global variable. Though app require db-like global state, it should be organized (as db is). Worth moving context management into separate service running in dedicated thread.It's the next feature to implement for two reasons:
cargo check
(or flow
or whatever).Intersection of what supported by kak-lsp and language server to be precise.
Hi
First, here's a screenshot of a *diagnostics*
buffer produced by the lsp-diagnostics
command. (using flow but it's not relevant here):
As you can see that's a lot of cyan
color. This buffer has the grep
filetype so it uses the highlighters defined here: https://github.com/mawww/kakoune/blob/master/rc/core/grep.kak#L30-L34 . That's where the cyan
and green
colors come from.
What would be the better way to improve the readibility?
For instance I think lines containing diag-messages like - Either string [1] is incompatible with string literal
article [2].
on the screenshot should simply be displayed with the Default
face.
Should it be fixed in kakoune's grep.kak
directly ? Or should kak-lsp
provides a custom diagnostics
filetype and related highlighters?
It could significantly ease installation and usage (no need to mess with user's ~/.config/kak/
, no need to keep in sync port etc.)
Scenario is:
lsp-enable
user adds `%sh{kak-lsp --enable}kak-lsp --enable
returns current lsp.kak
contents with proper lsp_cmd
based on config. Some of sections could be made controllable by config options.And provide command to enable/disable it. In general, we should not provide options for things easily doable as Kakoune command.
Looks like some zombie processes are hanging around during kak-lsp work:
rprakapchuk 30716 0.0 0.0 0 0 ?? Z 8:00pm 0:00.00 (kak)
rprakapchuk 30706 0.0 0.0 0 0 ?? Z 8:00pm 0:00.00 (kak)
rprakapchuk 30693 0.0 0.0 0 0 ?? Z 8:00pm 0:00.00 (kak)
rprakapchuk 30658 0.0 0.0 0 0 ?? Z 8:00pm 0:00.00 (kak)
It could be because how netcat is used (timeout?) and requires further investigation.
It's already possible by manual tweak of kak-lsp --kakoune
output being put into autoload
but we need to provide easy way to perform basic operations like enable/disable without resorting to static .kak
file (which is not bad by itself, but just tedious to keep in sync taking in account that kak-lsp is still in flux). Any thought on how should it look like and what configuration options should be implemented first?
Apparently uri
crate doesn't do it by default which leads to url-encoded paths to be sent to Kakoune (i.e. when doing goto definition)
If kak-lsp was crashed or exited by timeout after certain period of user inactivity then its restart should be automated. Current integration with Kakoune provides only automatic start on Kakoune session start and lsp-start
command to restart manually.
Same behavior on linux and macOS with rust 1.26.
May 28 08:52:13.341 DEBG To server: {"jsonrpc":"2.0","method":"textDocument/completion","params":{"position":{"character":12,"line":21},"textDocument":{"uri":"file:///Users/casimir/dev/src/github.com/casimir/ced/core/src/main.rs"}},"id":65}, module: kak_lsp::language_server_transport:152
May 28 08:52:13.355 DEBG From server: {"jsonrpc":"2.0","id":65,"result":[{"label":"env","kind":9,"detail":"/Users/casimir/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/env.rs"}]}, module: kak_lsp::language_server_transport:124
May 28 08:52:13.359 DEBG To editor `58887`: eval -client unnamed0 %🦀set window lsp_completions %§22.10@11:env|/Users/casimir/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/env.rs
|env {MenuInfo}Module§
🦀, module: kak_lsp::editor_transport:71
May 28 08:52:14.094 DEBG From editor:
session = "58887"
client = "unnamed0"
buffile = "/Users/casimir/dev/src/github.com/casimir/ced/core/src/main.rs"
version = 11
method = "textDocument/hover"
[params.position]
line = 21
character = 12
, module: kak_lsp::editor_transport:26
Related to #38
I wasn't able to compile in macOS.
❯ cargo build --release
Compiling kak-lsp v0.1.0 (file:///Users/vbauer/kakplug/kak-lsp)
error[E0554]: #![feature] may not be used on the stable release channel
--> src/main.rs:1:1
|
1 | #![feature(match_default_bindings)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error[E0554]: #![feature] may not be used on the stable release channel
--> src/main.rs:2:1
|
2 | #![feature(try_trait)]
| ^^^^^^^^^^^^^^^^^^^^^^
error[E0554]: #![feature] may not be used on the stable release channel
--> src/main.rs:3:1
|
3 | #![feature(getpid)]
| ^^^^^^^^^^^^^^^^^^^
error: aborting due to 3 previous errors
error: Could not compile `kak-lsp`.
I still get those when cquery crashes:
thread '' panicked at 'Failed to write message to language server: Os { code: 32, kind: > BrokenPipe, message: "Broken pipe" }', libcore/result.rs:945:5
It used to be that way and should be good for performance. I changed it to sending requests for all filetypes to make setup easier (no need to keep lsp.kak
and kak-lsp.toml
in sync, just single lsp-enable
is enough; no need to manage scoped hooks, just set global ones).
Worth to optimize it back after #20 which will allow to keep setup simple while deriving lsp.kak
dynamically from kak-lsp.toml
.
kak-lsp is not perfect and could crash from time to time and then being restarted. Or restarted deliberately during development of it. Or user can forget to fire up kak-lsp before starting work on project. It's very annoying to either re-open or execute lsp-did-open for files in Kakoune in both cases.
Because information about open files is already available in context, it should be easy to send didOpen to language server when it was not sent to it before for any reason.
Language server can provide parameter names and documents while typing parameters, see signatureHelper.
bin(
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"signatures": [
{
"label": "Return the binary representation of an integer.",
"documentation": "Return the binary representation of an integer.\n\n>>> bin(2796202)\n0b1010101010101010101010",
"parameters": [
{
"label": "number",
"documentation": null
}
]
}
],
"activeSignature": 0,
"activeParameter": 0
}
}
I tested for a python file test.py.
command:
kak-lsp -vvv
Printed "DEBG Unable to detect project root for file /tmp/test.py
" every time.
When I added an empty requirements.txt next to the file it did work.
My suggestion would be to make project root optional since it does not contain information that is necessary for most functions.
To exit kak-lsp session (as opposed to lsp-exit which shutdowns language servers associated with current Kakoune session, but keeps kak-lsp running (useful in TC single-server mode))
Controller event loop became a plain mess which I'm ashamed of.
Use case: for javascript files I want diagnostics from both eslint and flow language servers.
...and gracefully exit attached language servers and dispatch/transport threads.
Could we/do we want to handle it more granular, per project?
We might want to have mode when after dot or other completion triggers it's enabled, but disabled after whitespace.
It'd be great to have prebuilts available for windows as well.
I'm investigating using kak-lsp as part of cquery e2e testing - ideally CI can just download the prebuilt (cquery CI runs on windows, macos, and linux).
Due to complaints from several users (me included) inline diagnostics has been disabled by default in a89a2e1. I think most users expect to have this enabled by default when using LSP and that disabling it provides a worse first experience.
Also I'd like to point that people most likely don't complain about the feature on itself but that diagnostics that are too visible. I think this is due to the choice of the faces used. For example Information
is really annoying in a buffer when using the gruvbox theme since the face is the same than the one of the main cursor. I guess Information
is more adapted for UI components like the info box than to display inline information.
The ideal solution UX-wise would be colored underline but this is pretty difficult to display in a terminal screen if not impossible. Testing with similar setups in other editors I found using only a foreground color to be the more adapted. Particularly with yellow for information and red for errors, a couple that work with most of color schemes.
In the end it would be useful to allow users to configure the faces used by kak-lsp, something like DiagnosticInfo
and DiagError
maybe? @mawww would it be overkill to add these as default faces in kakoune? That way it could be theme-specific.
Mapping extension to language and language to language server command should be configurable via configuration file. Port should be configurable via config file and cli option. Having configurable address is not crucial, but would be nice to have.
Preferred format for configuration file is TOML.
At the moment code is littered with unwrap
and expect
. Though they are legitimate in several places (we can't do anything smart besides of exiting with an error message, and panic is okay for it), it's not the case for many others.
Currently, at least according to the Linux installation instructions, kak-lsp runs as a system service which seems sub-optimal:
$PATH
appropriately for each project, but since kak-lsp runs as a service it can't see $PATH
changes.I would be much more comfortable with kak-lsp if it followed a model a little more like Kakoune or tmux:
$kak_session
so every Kakoune session gets its own LSP server.$PATH
and other settingsSuch a scheme should be just as convenient for the end-user as the current system (automatically starting the correct LSP server, automatically restarting after a crash, etc.), but should be more secure.
I understand this would be a big departure from kak-lsp's current architecture, but if you're open to the idea I'm willing to work on the implementation.
Support verbosity levels.
https://github.com/rust-unofficial/awesome-rust#logging might be useful in choosing library to use.
It's quite redundant (meta contains everything needed for text_document parameter in most cases). It's nice to have it mimicking LSP requests, but let's don't be fanatic about it.
See #21 (comment)
Good to have a list of problems in entire project, not only see them inline.
I'm wondering if it is possible to use kak-lsp outside of kakoune? I'd like to have a language server command-line client that I can use to test cquery. So far I've been working on my own solution, but it'd be a good idea not to duplicate the effort.
I need to browse the implementation more carefully, but I think cquery e2e testing has a few requirements:
Any thoughts? If you're not interested in usage outside of kakoune that's completely okay :)
23-Wed 01:00:04 Franciman not sure it will be significant, but it may be useful. Do you remember the completion problem I had, and you said that you are keeping track of the offset. I found out that in the response to the textDocument/complete request, there can also be a textEdit which contains the range of text to apply the text transformation to (in layman's words write the completion :P)
23-Wed 01:01:08 Franciman so instead of keeping track of the offset you can use the start position of the range of the text edit. This has also the advantage of being able to support, in future, the use of the textEdit, when you select a completion, which may be useful
23-Wed 01:02:04 Franciman since insertText field is deprecated in favor of the textEdit, when the text to insert is different from the label
I'm getting really frequent crashes when using kak-lsp and simply moving around in a file.
Here is a dump of a typical crash with full verbosity and RUST_BACKTRACE=1. I don't know any Rust so I can't be much help here, but it feels like a race condition of some sort.
I'm using kak-lsp 3.1.3 on WSL and the only language server I have installed is https://github.com/sourcegraph/go-langserver
Don't assume that all content send by server is utf-8.
It'd be great if kak-lsp could show references (textDocument/references
).
Random feedback: it took me a bit to get kak-lsp running since it requires GNU netcat. Debian seems to only have BSD netcat, so I had to build GNU netcat from source.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.