I’m trying to get lsp-julia to work in Emacs with its lsp-mode. I’ve hacked around on lsp-julia and it appears I’ve been able to get it to interact with lsp-mode and start the language server properly with 1.4.2 (it had its own issues), but now its hanging when trying to index a very small project with very small packages. Lsp-mode logging does not give a whole lot of info. I’m pretty sure it has to do with the JSON message passing, I think its possible lsp-mode’s JSON protocol/schema is incompatible because of some other errors that popped up that I’ve been able to resolve (maybe not properly).
I tried editing
jsonrpc/core.jl with some
@debug statements but it interferes with
stdin/stdout of the language server so I get a
JSONRPC endpoint type error. (
stdin is seen as
Is there a way I can initialize the language server and pipe its communication with Emacs lsp-mode to see whats going on?
Also, I’m very very new to Julia, so I’m probably a little over my head even trying to hack around on this and apologies if this makes no sense.
Thanks for the help
lsp-mode has what has seemed like adequate builtin facilities for inspecting the communication between the client/server. Are you sure enabled
(or you could just use eglot-jl which alreadly works quite well )
Otherwise your path of least resistance is probably to wrap the command that
lsp-julia uses to invoke the language server with
tee. It’s odd that
@debug is interfering; I’m pretty sure that it writes to stderr rather than stdout…
lsp-log-io is enabled, lsp also has
lsp-server-trace, which I’ve tried to enable, and this is the weirdest thing about it, and I only figured it out randomly, the julia server crashes immediately with a type error if I don’t have
lsp-server-trace set, bizarrely though, it has to be set to a bogus value,
(lsp-server-trace "verbose"), is the proper syntax but julia only wants to accept
(lsp-server-trace 'any-dumb-thing-except-a-string). Part of the reason I’m trying to get at it from the julia side.
As to eglot-- ha, yes…but now these lsp/julia oddities have put me on a personal mission just to see whats going on…
tee is a good suggestion, I will try that. The debug thing to
stdout is weird too. The language server has the option to invoke it with the err_handler, would that be any use to me?
I’ve only updated your script to use the new
LanguageServerInstance() syntax, I set the
symstore to nothing, because julia was complaining about that too.
Also, your eglot-julia looks awesome, I bet I end up jumping to that. Thanks for the help and the time you’ve already put into lsp-julia.
If the language server is crashing and you’re having trouble getting at the stacktraces, you could use
err_handler to write them to a file, but that’s about all it gets you.
For what it’s worth, I’m no longer maintaining lsp-julia (gdkrmr is), but I actively use eglot-jl, so I have a vested interest in keeping it working. It sounds from the issues I’ve peeked into that gdkrmr has it working outside of linting with his development fork. Have you tried that with the necessary hack on the LanguageServer.jl side?
shoot, I went through all those issues, I tried an older version of the patch that I think I found through yours or gdkrmr’s issue thread. Using the progtoken branch got me past the (lsp-server-trace “verbose”) crash but I still got the union type error. BUT! the:
InitializeParams fix got it working in combination with the ProgToken patch
InitializeParams constructor, replacing
convert(ProgressToken, dict["workDoneToken"]) . But I agree, a better solution would be to define a
ProgressToken constructor that does this.
I had tried that earlier on its own and with the old patched version and it didn’t work, thanks for pointing to that other branch! I don’t know why I couldn’t find it. The pending commit doesn’t have the
InitializeParams change in it so I wonder if it got working without that. (I’m on mac running 1.4.2)
Thanks for the help! This was bugging the hell out of me. Now I’m just going to use eglot-julia. ha.