When opening a large project, the initial indexing or cache loading process can be time-consuming, often leading to empty lists of semantic tokens for the initially opened files. While ccls prioritizes indexing these files, it’s unclear how to notify the client to refresh the files. The existing workspace/semanticTokens/refresh request, unfortunately, doesn’t accept text document parameters.
workspace/semanticTokens/refresh essentially tells the client that “something changed” and the client should request the tokens again. This applies to all text documents, so it’s not as efficient as it could be, but still will do the trick. I’m not sure why it was made as a request and not a notification, since it doesn’t assume any sync processing on the client.
Also, if I understand the spec correctly, instead of returning the empty lists of tokens initially, you could “block” and return the “real” results when they are finally available. The client should handle the long wait gracefully.
I am relying on workspace/semanticTokens/refresh as a “notification message” now.
Blocking the result likely does not work out because clients typically have a timeout error for requests.
I’ve seen the messages for both lsp-mode and neovim lsp.
Hm, https://github.com/emacs-lsp/emacs-ccls looks like it doesn’t work with eglot? The skipped ranges feature in emacs-ccls looks like it might be worth switching to lsp-mode for C++.
emacs & vscode help needed to port this feature :)
I am curious how to solve the refresh problem https://maskray.me/blog/2024-10-20-ccls-and-lsp-semantic-tokens#refresh
workspace/semanticTokens/refreshessentially tells the client that “something changed” and the client should request the tokens again. This applies to all text documents, so it’s not as efficient as it could be, but still will do the trick. I’m not sure why it was made as a request and not a notification, since it doesn’t assume any sync processing on the client.Also, if I understand the spec correctly, instead of returning the empty lists of tokens initially, you could “block” and return the “real” results when they are finally available. The client should handle the long wait gracefully.
I am relying on workspace/semanticTokens/refresh as a “notification message” now.
Blocking the result likely does not work out because clients typically have a timeout error for requests. I’ve seen the messages for both lsp-mode and neovim lsp.
Hm, https://github.com/emacs-lsp/emacs-ccls looks like it doesn’t work with eglot? The
skipped rangesfeature inemacs-cclslooks like it might be worth switching to lsp-mode for C++.