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.

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:

• send a message to the language server, wait for a reply
• send an arbitrary (ie, not hard-coded in kak-lsp) message and wait for a reply
• specify initialization options in the init message (though this can be worked around)

Any thoughts? If you're not interested in usage outside of kakoune that's completely okay :)

Related to #38

Intersection of what supported by kak-lsp and language server to be precise.

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.

Use case: for javascript files I want diagnostics from both eslint and flow language servers.

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))

...and gracefully exit attached language servers and dispatch/transport threads.

Could we/do we want to handle it more granular, per project?

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:

• #5
• Finer modularization
• Consistent naming
• No global state promiscuity. 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.

We already hit problems with netcat platform-specific behaviour twice (see #24 and #14). It might be worth incorporating that functionality in kak-lsp itself to ensure consistent behaviour.

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.

https://pastebin.com/Qj8TL2dG

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

And provide command to enable/disable it. In general, we should not provide options for things easily doable as Kakoune command.

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).

Controller event loop became a plain mess which I'm ashamed of.

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

• Publish releases at least for Mac OS and Linux (I need to setup cross-compilation for that)
• Handle configuration copying (via Makefile?)

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`.

We might want to have mode when after dot or other completion triggers it's enabled, but disabled after whitespace.

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.

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?

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.

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.

Specification

It's the next feature to implement for two reasons:

1. Completion, hover and definition removed overhead of switching to look into API docs or to grep project for many cases. Next huge overhead I'd like to remove is switching to cargo check (or flow or whatever).
2. Implementation of this feature require solving routing back to editor something which lacks meta from editor request and will open gate for other server-initiated requests.

Group locations by file and scan each file once.

Support verbosity levels.

https://github.com/rust-unofficial/awesome-rust#logging might be useful in choosing library to use.

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

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)

Currently, at least according to the Linux installation instructions, kak-lsp runs as a system service which seems sub-optimal:

• it takes exclusive ownership of a TCP port on the loopback interface. While TCP ports are fairly plentiful, memorable port-numbers are less so, lots of tools want to use one and it's hard to handle collisions gracefully.
• It's reasonable to have multiple versions of a compiler toolchain installed, and hence multiple LSP servers for a single language. Normally this is easy to handle by setting $PATH appropriately for each project, but since kak-lsp runs as a service it can't see $PATH changes.
• I'm just uneasy about a long-running, unauthenticated service, even one limited to the loopback interface, that will accept file-paths and spit back information about them.

I would be much more comfortable with kak-lsp if it followed a model a little more like Kakoune or tmux:

• kak-lsp requires a session identifier on the command-line; the Kakoune integration script might pick something like $kak_session so every Kakoune session gets its own LSP server.
• kak-lsp connects to a long-running server listening on a Unix domain socket named after the session identifier, or starts such a server if needed
  • the Unix domain socket should be owned by the current user and mode 0600 for security
• the long-running server starts and manages the relevant LSP servers, much as it already does, but since it's launched by kak-lsp it should automatically inherit the appropriate $PATH and other settings
• the long-running server may exit automatically after a certain period of time has elapsed without receiving a query over the socket

Such 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.

Sometimes particular language server crashes and kak-lsp starts shouting into the void for server's route. It should restart that language server instead.

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.

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 literalarticle [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:

1. instead of lsp-enable user adds `%sh{kak-lsp --enable}
2. 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.

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.

In many cases this autocompletion is useless and prevents from immediate tab insertion.

See #21 (comment)

Language server can provide parameter names and documents while typing parameters, see signatureHelper.

Sample response from pyls

Context with cursor at position 3

bin(

Response

{
  "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
  }
}

And generate relative paths.

Good to have a list of problems in entire project, not only see them inline.

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.

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 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.

Don't assume that all content send by server is utf-8.

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.

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

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.