[rwols]

Some servers take quite some time to return code actions (JETLS for example takes ~2 seconds for me).

When requesting such code actions from the command palette, it can be a little confusing to understand what is happening, as there is no feedback given when the code action results take ~2 seconds to compute.

This change shows the usual progress notification in the status bar when it's taking more than 200ms.

[jwortmann]

There is nothing wrong with this PR, but I just wonder do you know any server which does progress reporting based on our client-initiated progress via workDoneToken?

JETLS takes around 5ms for code action requests on my side, and I think what you're seeing is compile time latency, but that happens only on the very first request (for each request type). Maybe it's not worth to trigger the

LSP/plugin/core/active_request.py

Line 48 in 4e3828b

sublime.set_timeout_async(show, 200)

on every code action request just for that, unless there is a server which actually uses the progress reporting for code action requests? Or otherwise should we maybe just activate work done progress on all requests by default, because as mentioned compilation with JETLS happens for every request type. I see that currently it is only active by default on document symbols, workspace symbols, formatting and prepare call/type hierarchy. All of those requests are triggered only on demand via user action, but code action requests can also happen automatically on typing or cursor position change. So perhaps for efficiency we should limit that only to requests which must be triggered manually?

Or perhaps better to only activate progress if the request was triggered manually (via command palette or context menu or key binding), but not when triggered automatically?

[rwols]

There is nothing wrong with this PR, but I just wonder do you know any server which does progress reporting based on our client-initiated progress via workDoneToken?

• Off the top of my head, I remember pyright supporting this: Incorrect handling of client-initiatied progress microsoft/pyright#2545.
• clojure-lsp supposedly handles workDoneToken only for the initialize request: clojure-lsp/clojure-lsp@531e508. It can take a long time to parse class paths and jars, apparently.
• gopls handles workDoneToken only for the workspace/executeCommand request: x/tools/gopls: add support for provided WorkDoneToken in ExecuteCommand golang/go#40527. Here's the exact line in the source code. And here's the function that starts the progress reporter, falling back to server-initiated progress if there's no token. I'm not experienced enough with the Go language to know which commands gopls supports.

There doesn't seem to be much more... The trend seems to be that most language server authors opt for server-initiated progress (which I find less elegant, IMO, as client-initiated progress has the ability to restrict to a specific view/buffer, compared to server-initiated progress which always reports "for the whole window").

Whether the server supports workDoneToken or not, when setting progress=True in the Request we show some kind of hint in the status bar regardless.

JETLS takes around 5ms for code action requests on my side, and I think what you're seeing is compile time latency, but that happens only on the very first request (for each request type). Maybe it's not worth to trigger the sublime.set_timeout_async(show, 200) on every code action request just for that, unless there is a server which actually uses the progress reporting for code action requests?

The JETLS doesn't seem to cache this compilation for me. It always takes a long time to resolve the code action request (and other requests as well). Perhaps there's a setting I'm missing?

Regardless, there's other servers out there that are also not quite that rapid, for instance jdtls.

Or otherwise should we maybe just activate work done progress on all requests by default, because as mentioned compilation with JETLS happens for every request type. I see that currently it is only active by default on document symbols, workspace symbols, formatting and prepare call/type hierarchy. All of those requests are triggered only on demand via user action, but code action requests can also happen automatically on typing or cursor position change. So perhaps for efficiency we should limit that only to requests which must be triggered manually?
Or perhaps better to only activate progress if the request was triggered manually (via command palette or context menu or key binding), but not when triggered automatically?

Yes, I totally agree that:

• "background requests" (like code lenses, pull diagnostics, semantic tokens) should not display progress.
• "foreground", or user-triggered, or manually-triggered requests should display progress.

Code actions are also requested in the background. The background code actions don't display progress. The background code actions go through the SessionBuffer.request_code_actions_async path, which sets progress=False.

The foreground code actions go through the CodeActionsManager, which does set progress=True.

(I'm not sure why CodeActionsManager isn't used in SessionBuffer and related classes).

[jwortmann]

Code actions are also requested in the background. The background code actions don't display progress. The background code actions go through the SessionBuffer.request_code_actions_async path, which sets progress=False.

Oh, okay I think I missed that when I took a quick look. Then it should be fine to have progress active in that case.

(I'm not sure why CodeActionsManager isn't used in SessionBuffer and related classes).

I think CodeActionsManager always requests code actions from all available sessions. Which is useful when triggered manually. But iirc code actions are also updated automatically when new diagnostics arrive, and in that case we only want to send the request to that particular session, which is done in the method in SessionBuffer.

[netlify]

✅ Deploy Preview for sublime-lsp ready!

Name	Link
🔨 Latest commit	354672f
🔍 Latest deploy log	https://app.netlify.com/projects/sublime-lsp/deploys/6a55fc91039079000860f778
😎 Deploy Preview	https://deploy-preview-2987--sublime-lsp.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.