Add configurable diagnostic timing (debounce or on-save only)

[tnoABS]

Current behavior: clangd diagnostics run on every keystroke with a (probably) fixed internal debounce and cannot be adjusted by the user.

Requested features:

1. Configurable debounce delay

• Setting: clangd.diagnostics.debounceTime (integer, milliseconds)
• Effect: wait at least this long after the last keystroke before triggering diagnostics.

2. Diagnostics on save only

• Setting: clangd.diagnostics.runOnSave (boolean)
• Effect: disable live diagnostics; publish errors and warnings only when the file is saved.

Use cases:

• Prevent distracting re-analysis while typing comments or sketching code.
• Improve responsiveness in large codebases.
• Give users control over immediacy vs. performance trade-off.

[JVApen]

Debounce time is defined at https://github.com/llvm/llvm-project/blob/cb8b0cd2cfbe817253f2679df53dd7926a7e1894/clang-tools-extra/clangd/ClangdServer.h#L163

https://github.com/llvm/llvm-project/blob/cb8b0cd2cfbe817253f2679df53dd7926a7e1894/clang-tools-extra/clangd/TUScheduler.cpp#L1512

I don't know how VS Code interacts here. I'm aware of it sending cancelation requests. I don't know if it also has some debouncing logic

[isgursoy]

We are waiting for this for years... Clangd is pretty useless in vscode without having proper delay like Qt Creator.

[JVApen]

Feel free to create a PR for this

[isgursoy]

I feel free. Rather, I don't prefer investing any resources for such a project management.
#263

[Iritscen]

As far as attempts at implementing this feature, there's strpbrk's approach, linked to in the previous comment by isgursoy, and my approach, found here: #262 (comment) . Mine supports using (1) a configurable delay and (2) waiting to show diagnostics until you leave the current line of code. I'm not sure if either will be merged into the plugin, but if you want your second requested feature, not showing diagnostics until the file is saved, you can easily start with my approach and then look at strpbrk's to see how to hook the file save event, and then use that to trigger the showing of diagnostics as it is already done in my code. Actually I wouldn't mind simply adding that feature myself to my fork, it's a good idea.

[JVApen]

I'm a bit worried by having an implementation inside the vscode extension. My experience with VS Code is that the communication is not the important overhead. You would also introduce a second debounce as the server already has debounce logic. Interactions between those 2 systems might be hard to debug/control.
At the same time, you would create a solution that would also work for other IDEs.

[JVApen]

I think it would make sense to split out your change in 2 sequential PRs. One for the debounce timer and one for the after-line-change. We might also want to think about sending some info the server that indicates that the client extension already does debouncing and as such skips the debouncing on the server. (Which can be a separate PR).
@HighCommander4 : what do you think about the interaction of the 2 debounce systems?

[Iritscen]

I do regret committing both changes together, because the debounce timer was very simple, only a few lines of code, and the after-line-change code significantly complicates it. I can tease out the debounce code pretty easily and make it a separate PR.

I understand the concern about adding debounce on top of debounce, but the way the debouncing logic works in clangd is actually very different. If you look at these two places in clangd, events asking for diagnostics are given special treatment and not subject to the debounce. I had first started to experiment with changing this logic in order to add a diagnostic delay feature, but I didn't feel confident that I wouldn't cause regressions, because I didn't understand the reasoning behind the current approach.

The current behavior for the debounce in clangd that's defined as 50-500ms is that it doesn't seem to apply to diagnostics at all, but that seems odd because this comment indicates that diagnostics are exactly what is supposed to be debounced, and yet that struct is only used in one place – line 1521 in TUScheduler.cpp, right after the code which returns a delay of zero if any of the incoming requests are asking for diagnostics. Maybe I'm misunderstanding something?

[JVApen]

I have the exact same understanding of the code.

[Iritscen]

Also, when I changed those lines to allow diagnostic requests to qualify for debouncing, my experience was that the debounce setting still had no effect on when they were sent back to VSCode. I didn't investigate this long enough to find the reason because at that point I discovered that I could hook diagnostics on the way back in from clangd and moved to using that approach.