Implement comprehensive LSP debugging

[w0rp]

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.

• Is this just a problem with the user's configuration?
• Is it a problem in the user's environment?
• Is it a bug in the server?
• Is it actually a bug in ALE?
• Is it all of the above?

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.

• Completion data that is sent to the language server.
• Completion information that is received by a language server.
• Positions of cursors with the lines they are on and so on for hover information, finding references, and go to definition requests.
• When ALE tells a server that a document has changed.
• When ALE attempts to use a server to perform some action it doesn't support.
• Probably a whole lot more.

[teto]

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.

[w0rp]

Yep, more debug information will help a lot of people.

[gmacon]

As a workaround, I was able to debug an LSP issue by using this shell script as ale_command_wrapper:

#!/bin/sh

tee "$1.in" | "$@" 2>"$1.err" | tee "$1.out"

[masaeedu]

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

[w0rp]

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: https://github.com/microsoft/language-server-protocol/issues/737

[Risto-Stevcev]

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.

[hjwp]

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 ~/.local/bin/ale-command-wrapper.sh

Then, in in .vimrc, set ale_command_wrapper:

" 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 /tmp called eg /tmp/haskell-language-server.out.

[w0rp]

I like that suggestion as an easy way to get a log of things on Unix systems.

[hjwp]

for bonus points it would delete those files on exit! but my shell-fu isn't strong enough for that lol.

[hjwp]

~(it's actually completely broken for executables that have full paths. trying to fix)~ i tried to fix that. it works in at least one case lol

[hjwp]

@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"?

[jwodder]

So now that https://github.com/microsoft/language-server-protocol/issues/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?

[coffeebe4code]

rust-analyzer takes forever to start up for some reason. I would like some sort of callback as well. Would really help.