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.
Thanks
Decidedly kakoune is resourceful
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:
- Open the file with Kakoune in a specific session, e.g.
mysession
:kak -s mysession main.c
- In another terminal kill current instance of kak-lsp and run it with debug logging:
pkill kak-lsp; kak-lsp -s mysession -vvv
- 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
) - 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
- If it doesn’t happen then the problem is most likely with sockets.
- If it happens then the problem is most likely because
lsp.kak
fails to callkak-lsp --request
properly. In that case, it might worth settingset global debug shell
and checking if something suspicious happens when you execute, say,lsp-hover
.
I did as before and added your last test
- Open the file with Kakoune in a specific session, e.g.
mysession
:kak -s mysession main.c
- In a second terminal kill current instance of kak-lsp and run it with debug logging:
pkill kak-lsp; kak-lsp -s mysession -vvv
- Open a third terminal and
echo foo | kak-lsp -s mysession --request
- 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:
- You have the same
kakrc
andkak-lsp.toml
as in working setup on opensuse. - You open file with
kak -s mysession main.c
- You run kak-lsp server manually with
pkill kak-lsp; kak-lsp -s mysession -vvv
- It starts and doesn’t exit because of another server running.
- You call
:lsp-hover
in Kakoune, no error happens. - 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 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.
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