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

Maybe it could become a ranger plug-in ?
I need to have a look on andreyorst “fzf-project” which seems to be a good candidate to navigate in project.

You can use ranger with Connect.

connect ranger

Thanks
Decidedly kakoune is resourceful :slightly_smiling_face:

Hello ulis,
Is there a way to check that clangd is responding ?

Kak-lsp seems well set and is running. Kakoune also.

But when I open a cpp file , I can not see the error bar added in the number line columns. It should work even with no files in the root project (compile_flags.txt", “compile_commands.json”).

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.

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.

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.

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” ?

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.

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

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

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.

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?

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.

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 :

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

2 Likes

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

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.

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” ?

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

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