lsp-code-actions getting spammed on typescript-language-server

[QuinnFreedman]

I configured kak-lsp for typescript using typescript-language-server. It works fine, except there seems to be very weird behavior around lsp-code-actions.

Whenever I press ANY KEY or make any input whatsoever, it seems to try to run lsp-code-actions. Most of the time, this results in the kak-lsp: no actions available popup. But, when there actually should be some actions available, it does nothing at all. No popup, no error message, no code change. When I manually run lsp-code-actions, the same thing happens.

Checking the debug buffer shows nothing but a long list of kak-lsp: no actions available. I'm not sure how to debug further.

I got this error on outdated versions of kakoune and kak-lsp, so I updated both to the newest version and the issue persisted. I have never had this issue with other LSP servers, but I haven't tried that many so I don't know if it's unique to typescript.

Here is my config if you want to try to replicate it:

$ kak -version
Kakoune v2021.08.28-93-g6e635ea3
$ kak-lsp --version
kak-lsp 11.0.1
$ typescript-language-server --version
0.6.4

kak-lsp.toml

[language.typescript]
filetypes = ["typescript"]
roots = ["package.json", "tsconfig.json"]
command = "typescript-language-server"
args = ["--stdio"]

kakrc

plug "ul/kak-lsp" do %{
    cargo install --locked --force --path .
} config %{
    hook global WinSetOption filetype=(elm|rust|python|go|javascript|typescript|c|cpp|kotlin|dart|tsx) %{
        lsp-enable-window
        lsp-auto-hover-disable
        lsp-auto-signature-help-disalbe
        hook window BufWritePre .* lsp-formatting-sync
    }

    map global user h :lsp-hover<ret> -docstring 'LSP hover'
    map global user p :lsp-signature-help<ret> -docstring 'LSP signature'
    map global user g :enter-user-mode<space>lsp<ret> -docstring 'LSP'
}

[krobelus]

Whenever I press ANY KEY or make any input whatsoever, it seems to try to run lsp-code-actions. Most of the time, this results in the kak-lsp: no actions available popup.

Thanks for reporting - that sounds like an old kak-lsp binary serving a Kakoune session that loaded a new rc/lsp.kak (which demands code actions)

$ kak-lsp --version
kak-lsp 11.0.1

Yeah, 11.0.1 didnt't include the lightbulb feature. I can reproduce by placing kak-lsp 11.0.1 first in my $PATH and loading the latest kak-lsp manually (without plug.kak) with source path/to/kak-lsp/rc/lsp.kak

plug "ul/kak-lsp" do %{ cargo install --locked --force --path .

When updating, plug.kak first runs a "git pull", and then runs the "cargo install" command. If you wait for that to complete, kak-lsp --version should show kak-lsp 11.0.1-snapshot. It sounds like you either don't have ~/.cargo/bin on your $PATH, or you canceled the "cargo install" command (in that case, run it manually).

I wonder how we can detect cases like these without breaking other use cases (I always source rc/lsp.kak manually when hacking on kak-lsp, so I don't need to recompile).

(I added a test in 371d5cc that demonstrates that typescript-language-server + code actions work on latest master)

    lsp-auto-signature-help-disalbe

disalbe -> disable (or leave it out since it's disabled by default)

[QuinnFreedman]

Thanks. This makes sense. Actually, I got an error whenever I tried to plug-update with cargo so I just pulled the binary from releases but it's probably not the same version as lsp.kak which is coming from master.

It's probably because I'm or WSL1 which has had weird problems running rustc in the past.

With that in mind I can probably find some workaround.

I wonder if it would be possible to add either a compile or pre-commit hook to add a build number or commit hash to both lsp.kak and the binary. Then the plugin could complain if they don't match. This is probably a pretty niche problem though so maybe not worth the effort.

[krobelus]

If you're fine with the released version, then you can load kak-lsp without plug.kak Or you can tell plug.kak to use a specific tag

We could also offer nightly binaries, that shouldn't be difficult.

Yeah, we can definitely warn if the binary/lsp.kak mismatch (but allow to turn off that warning). Helps some users and hurts no one. Though of course that's a workaround. For kak-lsp it would make more sense if plug.kak didn't source rc/lsp.kak. There's a keyword in plug.kak to do that - noload,