0

I'm running into an awkward bug with lsp-mode + clangd for batch editing files.

When a source file is loaded, the symbols it points to aren't immediately available (using xref-find-definitions for example).

Calling xref-find-definitions fails on a newly loaded buffer.

Adding a sleep timer: e.g: (sleep-for 3.0) then calling xref-find-definitions works as expected (showing the header for an implementation of a function for example).

How can this be handled more reliably than sleeping and hoping the file references have loaded?

For reference

Improve this question
7
  • Try instead the function lsp-find-definition, bounded to <s-l> gg - is that also slow? (without sleep).
    – Ian
    Dec 1, 2021 at 13:02
  • All I get is this: LSP :: Connected to [clangd:57835/starting]. Debugger entered--Lisp error: (error "The connected server(s) does not support method te...") error("The connected server(s) does not support method %s..." "textDocument/definition") lsp--send-request-async((:jsonrpc "2.0" :method "textDocument/definition" :params As wirh xref, calling(sleep-for 3.0) beforehand solves.
    – ideasman42
    Dec 3, 2021 at 4:59
  • What lsp version do you have? Also, do you use cmake to have a compile_command.json file? Maybe posting some parts of your configuration will help. The lsp-mode uses part of xref core, not xref itself. A lag could be normal, until the file is indexed.
    – Ian
    Dec 3, 2021 at 14:00
  • Use this: emacs-lsp.github.io/lsp-mode/tutorials/CPP-guide as guide - with the mention I do not use helm-xref.
    – Ian
    Dec 3, 2021 at 14:06
  • In Emacs check the variable exec-path- should contain clangd's path.
    – Ian
    Dec 3, 2021 at 14:41

1 Answer 1

Reset to default
0

Emacs doesn’t index the file, the LSP server does (in this case that is clangd). The LSP protocol supports asynchronous notifications when results are available, so in principle clangd should be accepting your request and replying with a token that will identify the results when they are available. lsp-mode would then process the results as normal once it receives a notification with that token.

In the comments, you reported seeing these log messages:

LSP :: Connected to [clangd:57835/starting].
Debugger entered--Lisp error: (error "The connected server(s) does not support method te...")
error("The connected server(s) does not support method %s..." "textDocument/definition")
lsp--send-request-async((:jsonrpc "2.0" :method "textDocument/definition" :params

This indicates that clangd has not advertised that it supports looking up definitions. Since it then starts working a few seconds later, this sounds like a bug in clangd. Or maybe clangd just doesn’t support this at all, and you’re falling back to some other xref backend, in which case the answer to your question has nothing to do with lsp-mode at all. You should check the value of xref-backend-functions.

Edit: if the problem is simply that your batch process is running before the connection to the LSP server is fully established, then use the lsp-after-initialize-hook hook to start it instead.

Improve this answer
10
  • re: This indicates that clangd has not advertised that it supports looking up definitions. - in that case, can this be checked?
    – ideasman42
    Dec 4, 2021 at 11:55
  • Yes. Run M-x lsp-describe-session. This will show you the capabilities of each LSP server that Emacs is connected to. Look for the definitionProvider capability.
    – db48x
    Dec 4, 2021 at 12:12
  • Interesting, the definitionProvider is t, however this misses the point. All the capabilities I need are there, I just have no way (as far as I know) to check if they have been initialized yet or not for a given buffer in elisp (hence the arbitrary sleep which I would like to avoid). In short, there is a sleep-for command that should be replaced by a call to wait until the the lsp data is ready.
    – ideasman42
    Dec 5, 2021 at 2:05
  • lsp-after-initialize-hook only runs for the session, not after loading new files - so it's not a reliable way to know if a file has it's symbols loaded for lsp.
    – ideasman42
    Dec 5, 2021 at 23:04
  • The script you posted opens all files in the list first, and then starts processing them. Since it doesn’t wait for the LSP session to be established, it can easily finish opening them all before that happens. You need to wait for this event before you start doing any work.
    – db48x
    Dec 6, 2021 at 1:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.