Kakoune with Ubuntu WSL (windows platform) to use clangd with kak-lsp

[ulis]

Yes, the best way to check is to run kak-lsp server manually as I described. May be my instruction was confusing, let me try again:

1. Open the file with Kakoune in a specific session, e.g. mysession: kak -s mysession main.c
2. In another terminal kill current instance of kak-lsp and run it with debug logging: pkill kak-lsp; kak-lsp -s mysession -vvv
3. Switch to Kakoune and edit file or trigger interaction with kak-lsp for this buffer in any other way (e.g. by calling lsp-hover)
4. Switch back to another terminal and observe kak-lsp logs. They should give a hint about the situation: did kak-lsp succeed to start clangd, what were requests and responses and commands sent to Kakoune etc.

[lauccode]

Thanks ulis,
This is well explained. I tried in opensuse and I can trigger interaction.
But there is no event on WSL.
I updated to clangd 8.0.0 without more effects.

[ulis]

Just a wild guess: it might be a problem with sockets. kak-lsp tries to create a Unix socket in $TMPDIR/kak-lsp/$USER/ for communication between Kakoune and kak-lsp. Probably it fails to create a directory, or set rights, or something else under WSL. Unfortunately, I don’t have a Windows box at hand to test it by myself.

To test it you can try to run kak-lsp server manually as before and them to send a request to it manually as well: echo foo | kak-lsp -s mysession --request. If communication is successful then server should panic like this:

thread '<unnamed>' panicked at 'Failed to parse editor request: Error { inner: ErrorInner { kind: Wanted { expected: "an equals", found: "a newline" }, line: Some(0), col: 3, message: "", key: [] } }', src/libcore/result.rs:997:5 

1. If it doesn’t happen then the problem is most likely with sockets.
2. If it happens then the problem is most likely because lsp.kak fails to call kak-lsp --request properly. In that case, it might worth setting set global debug shell and checking if something suspicious happens when you execute, say, lsp-hover.

[lauccode]

I did as before and added your last test

1. Open the file with Kakoune in a specific session, e.g. mysession : kak -s mysession main.c
2. In a second terminal kill current instance of kak-lsp and run it with debug logging: pkill kak-lsp; kak-lsp -s mysession -vvv
3. Open a third terminal and echo foo | kak-lsp -s mysession --request
4. Switch back to second terminal and observe kak-lsp logs. They should give a hint about the situation: did kak-lsp succeed to start clangd, what were requests and responses and commands sent to Kakoune etc.
   Here I can see the log in terminal

$ kak-lsp -s mysession -vvv Apr 25 16:01:53.564 INFO Starting main event loop, module: kak_lsp::session:31 thread ‘Apr’ panicked at ’ Failed to parse editor request: Error { inner: ErrorInner { kind: Wanted { expected: “an equals”, found: “a newline” }, line: Some(0), col: 3, message: “”, key: } }25’, libcore/result.rs16::10090:25: 0note: Run with RUST_BACKTRACE=1 for a backtrace. 1.009 DEBG From editor: foo , module: kak_lsp::editor_transport:153 Apr 25 16:02:01.010 INFO Shutting down language servers and exiting, module: kak_lsp::session:191

It seems we are in case 2. ?
How could I “setting set global debug shell” ?

[ulis]

@lauccode

How could I “setting set global debug shell” ?

Just execute it as a command in Kakoune: :set global debug shell. You’ll get a log of shell commands in the *debug* buffer then.

[lauccode]

I launched kakoune
Do the command :set global debug shell
and command :lsp-hover
So, I retrieved debug.txt but I’m not able to analyze it …
I put the file on my Github config if you could have a look and found the issue ->
https://github.com/lauccode/config/blob/master/debug_kak_lsp.txt

[ulis]

From the log it seems that lsp.kak is able to call kak-lsp --request. Just to double check, you don’t see any debug messages printed by kak-lsp server which you run manually with -vvv flag, do you? It’s very strange… Why can’t kak-lsp client reach the server… Sorry for making circles, but just to be completely sure that I understand what happens, do my description matches your experience:

1. You have the same kakrc and kak-lsp.toml as in working setup on opensuse.
2. You open file with kak -s mysession main.c
3. You run kak-lsp server manually with pkill kak-lsp; kak-lsp -s mysession -vvv
4. It starts and doesn’t exit because of another server running.
5. You call :lsp-hover in Kakoune, no error happens.
6. You don’t see anything in kak-lsp server logs after Starting main event loop message.

Is it true, or did I confused any step (especially curious about the last one)?

[lauccode]

Hi,
There no messages when I run kak-lsp -s mysession -vvv manually with -vvv flag.

1.To be sure, I redo the test on opensuse and WSL with the configuration files retrieved on Gitub. So, I got the same

• .tmux.config
• kakrc
• kak-lsp.toml

2.Yes, I open with kak -s mysession src/ball.cpp
3. Yes, I do

pkill kak-lsp
kak-lsp -s mysession -vvv

4.It starts like so >

$ kak-lsp -s mysession -vvv
May 02 14:30:19.054 INFO Starting main event loop, module: kak_lsp::session:31

But no more info when I come back in Kakoune.

5.I call :lsp-hover in Kakoune and I see no errors.
In the debug buffer I can see >

*** This is the debug buffer, where debug info will be written ***
Dependency unmet: gocode, please install it to use go-tools
Dependency unmet: goimports, please install it to use go-tools
Dependency unmet: gogetdoc, please install it to use go-tools
Dependency unmet: jq, please install it to use go-tools
Config-change detected:**

6.No, I don’t see anything in kak-lsp server logs(terminal info updated as with opensuse, it is not a file) after kak-lsp -s mysession -vvv as in 4.

[ulis]

So, you don’t see any logs printed by kak-lsp -s mysession -vvv even on opensuse, but it works fine on it? Plot thickens!

I’m short of ideas! Another wild guess is that kak-lsp called from Kakoune and the one started manually belong to different users, not sure how is it possible. Do you see multiple directories inside $TMPDIR/kak-lsp?

[lauccode]

No, the log on opensuse are good, it is working well.
I only described on WSL which has the issue and no log.
I did the same test with the same github files on opensuse and WSL.
This is OK on opensuse, I use it as a reference. And I do the same on WSL with the issue.
I do the test on WSL and echo $TMPDIR is empty.

From that I saw on opensuse, as soon as I open a .cpp, I can see some log on the other terminal with ’ kak-lsp -s mysession -vvv'. It is as if on WSL kak-lsp is not working at all.

[lauccode]

Ok, I got it.
I added kak-lsp binary in ~/.local/bin (so added in PATH) and it is working well.
Strangly before that I could launch kak-lsp from anywhere.
I will try to find what I missed with plug.kak …
The good way is as andreyorst explained :

I don't succeed to use cquery (kak-lsp)

No, this is usual behavior. I suppose that you’ve installed kak-lsp by manually cloning the repo, and then added the plug.kak config for it. That’s not the proper way how to install plugins with plug.kak. Because if you install it via plug-install it will run post-install hooks, which are compilation and installation (if specified). So there’s no need to place a symbolic link in your /usr/local/bin, instead, you should check where cargo installs kak-lsp and add this folder to $PATH. My recom…

But I have some trouble on the computer to do git clone or apt-get install, I need to switch network…

Ok, so, good new, we can work with Kakoune on Windows with WSL.
I think I saw maxxx is already working well with WSL on other post. Now I can confirm it is working too.

Thanks ulis and andreyorst.

[lauccode]

Sorry, but how to be sure “compile_commands.json” has been loaded ?

[FlyingWombat]

How did you build kak-lsp on Windows? Or can WSL run unix binaries as-is?
I don’t have WSL (Windows 7); I’m using Msys2 instead. And when I tried to build kak-lsp using Windows native Rust, it (as expected) failed, with an error on the ‘daemonize’ crate saying it couldn’t find “unix” or something like that.

[lauccode]

Yes, I can use kakoune on WSL as on Linux distribution.
Kak-lsp is installed with the plugin plug.kak of andreyorst
I’m just wondering when I open kakoune kak-lsp is really loading the “compile_commands.json” ?

[ulis]

I’m just wondering when I open kakoune kak-lsp is really loading the “compile_commands.json” ?

kak-lsp is not loading this file at all, it’s a responsibility of cquery/ccls/clangd. To ensure that those language servers are getting a proper project root (and a chance to load compile_commands.json), just make compile_commands.json the only project root marker for them, i.e.:

[language.c_cpp]
filetypes = ["c", "cpp"]
roots = ["compile_commands.json"]
command = "clangd-mp-8.0"
offset_encoding = "utf-8"
[language.c_cpp.initialization_options]
offsetEncoding = ["utf-8"]

Running kak-lsp with debug log will show you messages from language servers as well, which might help to diagnose if they were able to load compile_commands.json

[andreyorst]

For clangd I recommend to include compile_flags.txt as root marker as well, since it can work with that too, when compile_commands.json is not available.

roots = ["compile_flags.txt", "compile_commands.json"]

compile_flags.txt follows this simple format, where each flag is on a new line:

%c -Weverything -Wall --std=c99
-I./include