-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Duplicate color provider references #2534
Comments
Thanks for the report. I believe it happens because this entire block in the Lines 346 to 356 in 9065e1f
This runs after document changes, but for each SessionBuffer (i.e. for each language server). I think that
For the mentioned features that are rendered in the view (e.g. via phantoms) it should be handled in
Lines 369 to 382 in 9065e1f
Edit: this part might be fine because the "pending refresh" is stored per SessionBuffer. Unless some server sends I might take a look over the weekend and see if I can fix it. Related recent discussion also at #2526 |
I think I also saw similar issues for document links. For example, you could have |
I remember working on that in the past but I was stopped in tracks due to sublimehq/sublime_text#6188. |
Okay but that still looks like a different issue to me because here we don't have any cloned views. I would think the cause of the bug described in this issue here is that color boxes, inlay hints, etc. are requested and stored per SessionBuffer: Line 130 in 9065e1f
There is always exactly one DocumentSyncListener per view, but if you have two language servers running there will be two SessionBuffer objects. Although the phantom sets seem to share the same key "lsp_color", so I assume they should just overwrite each other... but perhaps this is also part of the cause for the bug. If the Similarly if semantic tokens were stored in DocumentSyncListener instead of SessionBuffer, I might be wrong but iirc some time ago more of the code was initially in DocumentSyncListener, but then it was refactored and moved into the |
This is a bit tricky to fix. It seems doing the color boxes was moved from DocumentSyncListener to SessionBuffer in 2b98639 to ensure proper ordering between the Line 305 in 9065e1f
So I would say that in SessionBuffer there must be no debouncing; instead this whole block should be moved to DocumentSyncListener, and then Lines 285 to 306 in 9065e1f
This should only run for the DocumentSyncListener of the primary view, so that the methods in SessionBuffer won't get additionally called by listeners from cloned views. Currently we have that condition here: Lines 330 to 333 in 9065e1f
And then the PhantomSet could still be stored in the SessionBuffer (if necessary due to ST API behavior) because the corresponding update method would only be called for one of the SessionBuffers. By the way, @rchl already recognized this problem in #1899 (comment):
I would say that it's not the right thing to request features which are rendered in the view (color boxes, inlay hints, ...) from all sessions. And the majority of users probably just use the default configuration and are not aware that something like "disabled_capabilities" exists (besides that, as pointed out in sublimelsp/repository#120 (comment) it is not always desired to disable it completely). So I think we should try to give the best default experience and only request those features from the |
I kinda feel like technically handling it from SessionBuffer is the correct thing to do since the result is specific to the particular session. We might want to instead try to figure out how to make the SessionBuffer dynamically decide whether it should perform the request or not and not move any logic from there. EDIT: Sorry, that's what you said more or less. Did not read your (big) comment properly. |
Describe the bug
When using two or more language servers which have color provider functionality, there are situations when duplicate references are displayed. This is most recently visible when using LSP-volar and LSP-sass for Vue SFC files.
To Reproduce
Steps to reproduce the behavior:
$color
variableExpected behavior
Only one color provider reference is displayed.
Screenshots
Actual:
Expected:
Logs
N/A
Environment (please complete the following information):
Additional context
As mentioned in sublimelsp/repository#120 (comment), this is probably related to Sublime LSP. My initial reaction was that it’s related to how Volar packages language servers and since there are no hooks with which you can control those servers (at least I haven’t found them), there isn’t really much you can do except disable
colorProvider
in one of the servers, but that relates to all server functionalities. What you actually want is to disable color provider on SFC Sass style blocks.The text was updated successfully, but these errors were encountered: