-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement comprehensive LSP debugging #2137
Comments
Sounds neat. Right now, hie doesn't work in ale and I have no idea why while LanguageClient-neovim logged everything to a file, helping me troubleshooting the root cause. |
Yep, more debug information will help a lot of people. |
As a workaround, I was able to debug an LSP issue by using this shell script as #!/bin/sh
tee "$1.in" | "$@" 2>"$1.err" | tee "$1.out" |
I'd like to be able to show the overall LSP status somewhere in my airline, so I can figure out whether I can't see errors yet because there really are no errors, or because the LSP hasn't finished reporting in yet. This is especially important for large projects in languages with slow compilation (e.g. Haskell). |
Unfortunately Language Server Protocol makes that impossible. I opened an issue with a suggestion that would make that possible for servers that implemented an addition to the specification: microsoft/language-server-protocol#737 |
What can people do in the meantime? I'm trying to get the new and official ocamllsp working but can't. I ran into the issue before and I thought I remember something about being able to read a log file but I'm not sure, it's just silently failing right now. |
Here's something I found somewhere, sorry I can't find it any more to give credit. First, create a little wrapper shell script whose job it is to capture input, output, and stderr, and write them to files #!/bin/bash
executable=$1
outputfile=${executable////-} # strip out /es if executable is full path
# OK DO NOT USE THIS ACTUALLY COS TEE DOES SOME SORT OF BUFFERING OF STDIO
# WHICH WILL CAUSE SOME PROCESSES TO HANG. LIKE LINTERS.
exec tee "/tmp/$outputfile.in" | "$@" 2>"/tmp/$outputfile.err" | tee "/tmp/$outputfile.out" save that to somewhere on your path, eg Then, in in .vimrc, set " this allows you to debug interactions with language servers
let g:ale_command_wrapper = '~/.local/bin/ale-command-wrapper.sh' now whenever vim spins up a language server, it'll go via the command wrapper, which will dump files into |
I like that suggestion as an easy way to get a log of things on Unix systems. |
for bonus points it would delete those files on exit! but my shell-fu isn't strong enough for that lol. |
|
@w0rp I've been banging my head against getting that wrapper to work reliably but shell buffering stuff is hard to wrangle. would you be interested in a small cash subsidy for working on the LSP debugging feature "properly"? |
So now that microsoft/language-server-protocol#737 is resolved as of a year and a half ago, how can one make it work with ale in order to get LSP status in the statusline? |
rust-analyzer takes forever to start up for some reason. I would like some sort of callback as well. Would really help. |
ALE supports a variety of Language Server Protocol features, and they generally work pretty well, but there is one glaring issue with Language Server Protocol. How do you figure out what is going wrong or where? Every time an issue is reported, you have to ask the following questions.
There's no easy way to answer any of these questions, and most users have no hope of figuring it out themselves. To that end, I propose that we add support for comprehensively debugging LSP server communication, which will be disabled by default, which will print incredibly verbose information about what ALE is trying to do. We can log the following when the option is turned on.
The text was updated successfully, but these errors were encountered: