You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using SonarLint CFamily via lsp-sonalint. Unfortunately, the CFamily analyzer is pretty slow at the moment, and it take several seconds and up to a minute to analyze a file after it has been changed.
In the meantime, while I edit the contents, issue locations become stale and point to the wrong parts.
Here is an example:
The SonarLint diagnostic about a TODO comment starts off correctly on the TODO comment (on line 13).
When I delete a line, the diagnostic line stays the same, but the the TODO comment is now actually on line 12,
so I get a confusing issue location.
I then wait for a few seconds for SonarLint to publish the updated set of diagnostics, and the diagnostic location gets the correct line 12.
However, I often edit the files continuously and this problem arises on every line deletion/insertion, so the diagnostics constantly point to the wrong locations.
I've noticed similar problem with clangd but to a lesser degree, since it has much shorter turn-around time.
I could set lsp-diagnostic-clean-after-change to remove the diagnostics altogether, but that means I'd need to restrain myself from changing a file for a few seconds or a minute to see the diagnostics.
Solution
I propose to adjust the diagnostic locations on every change.
Particularly, I would go through the list of diagnostics and check which ones have a location that is after the change, and increment/decrement them to the corresponding amount.
Implementation
My plan is the following:
Add a few regression tests around the display of diagnostics using a mock LSP server.
Modify the "position" plist from (:line :character) to (:line :character :point) (where :point is optional), and set :point to the
absolute offset from the beginning of the buffer, i.e. the (point) value at the corresponding line and character. I'd need to clarify what to do with the "virtual buffers" created for org-mode code snippets.
In the lsp-on-change add an alternative to cleaning up all diagnostics - adjusting the diagnostics:
Iterate over the diagnostics and for each end of a diagnostic range
if its :point is before the start of the modified region, keep it as is
if its :point is after the start + length of the modified region, increase/decrease it to reflect the length shift
if its :point is between start and start + length, set it to end
Then remove the diagnostics with empty ranges.
Discussion
Have you experienced similar issues?
Is my plan sound? Do you think it can degrade lsp-mode performance? Any pitfalls I should watch out for?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
The problem
I am using SonarLint CFamily via lsp-sonalint. Unfortunately, the CFamily analyzer is pretty slow at the moment, and it take several seconds and up to a minute to analyze a file after it has been changed.
In the meantime, while I edit the contents, issue locations become stale and point to the wrong parts.
Here is an example:
The SonarLint diagnostic about a TODO comment starts off correctly on the TODO comment (on line 13).
When I delete a line, the diagnostic line stays the same, but the the TODO comment is now actually on line 12,
so I get a confusing issue location.
I then wait for a few seconds for SonarLint to publish the updated set of diagnostics, and the diagnostic location gets the correct line 12.
However, I often edit the files continuously and this problem arises on every line deletion/insertion, so the diagnostics constantly point to the wrong locations.
I've noticed similar problem with clangd but to a lesser degree, since it has much shorter turn-around time.
I could set
lsp-diagnostic-clean-after-change
to remove the diagnostics altogether, but that means I'd need to restrain myself from changing a file for a few seconds or a minute to see the diagnostics.Solution
I propose to adjust the diagnostic locations on every change.
Particularly, I would go through the list of diagnostics and check which ones have a location that is after the change, and increment/decrement them to the corresponding amount.
Implementation
My plan is the following:
Add a few regression tests around the display of diagnostics using a mock LSP server.
Modify the "position" plist from
(:line :character)
to(:line :character :point)
(where:point
is optional), and set:point
to theabsolute offset from the beginning of the buffer, i.e. the
(point)
value at the corresponding line and character. I'd need to clarify what to do with the "virtual buffers" created for org-mode code snippets.In the
lsp-on-change
add an alternative to cleaning up all diagnostics - adjusting the diagnostics:Iterate over the diagnostics and for each end of a diagnostic range
:point
is before thestart
of the modified region, keep it as is:point
is after thestart + length
of the modified region, increase/decrease it to reflect the length shift:point
is betweenstart
andstart + length
, set it toend
Then remove the diagnostics with empty ranges.
Discussion
lsp-mode
performance? Any pitfalls I should watch out for?Beta Was this translation helpful? Give feedback.
All reactions