Skip to content
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

Open
w0rp opened this issue Dec 10, 2018 · 13 comments
Open

Implement comprehensive LSP debugging #2137

w0rp opened this issue Dec 10, 2018 · 13 comments
Labels
enhancement LSP Any issue relating to LSP or tsserver
Milestone

Comments

@w0rp
Copy link
Member

w0rp commented Dec 10, 2018

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.
@w0rp w0rp added enhancement LSP Any issue relating to LSP or tsserver labels Dec 10, 2018
@teto
Copy link

teto commented Dec 14, 2018

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
Copy link
Member Author

w0rp commented Dec 15, 2018

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

@gmacon
Copy link

gmacon commented Apr 12, 2019

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
Copy link

masaeedu commented Jun 7, 2019

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
Copy link
Member Author

w0rp commented Jun 8, 2019

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

@Risto-Stevcev
Copy link
Contributor

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
Copy link
Contributor

hjwp commented Mar 12, 2021

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
Copy link
Member Author

w0rp commented Mar 15, 2021

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

@hjwp
Copy link
Contributor

hjwp commented Mar 16, 2021

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

@hjwp
Copy link
Contributor

hjwp commented Mar 17, 2021

(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
Copy link
Contributor

hjwp commented May 13, 2021

@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
Copy link

jwodder commented Nov 24, 2023

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?

@coffeebe4code
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement LSP Any issue relating to LSP or tsserver
Projects
None yet
Development

No branches or pull requests

8 participants