-
Notifications
You must be signed in to change notification settings - Fork 188
Refactor code lenses #2677
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
Refactor code lenses #2677
Conversation
✅ Deploy Preview for sublime-lsp ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
This comment was marked as outdated.
This comment was marked as outdated.
|
When split view is opened it does not show code lenses until selection changes. Not sure if it was like that before also... |
Co-authored-by: Rafał Chłodnicki <rchl2k@gmail.com>
✅ Deploy Preview for sublime-lsp ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
I will look into that tomorrow or over the weekend and do some more testing for edge cases. Edit: fixed in e473dbf |
|
We have to release new LSP version ASAP since there are things relying on it. Hope everyone is fine with that. :) |
Continuing from #2666
I refactored and renamed CodeLensView and moved the handling from SessionView to SessinBuffer, so that it is not done in parallel with the same data in case there are cloned (split) views. I have kept the caching for the annotations/commands and re-enabled resolving for the visible viewport area after selection change, which was accidentally removed in #2666. Unfortunately if the server uses
codeLens/resolvethe code lenses don't work great together with the filtering of supported commands. But it should be fine at least for the current viewport area due to the implemented caching. If you scroll away, you might need to click into the viewport (to change the selection and trigger resolve) before code lenses show up. But I also made some improvements for the caching:The previous implementation first converted the line and column based LSP
Rangeto asublime.RegionLSP/plugin/code_lens.py
Line 59 in 72e6516
and then used that
Regionas the key to store code lenses grouped by region:LSP/plugin/code_lens.py
Line 140 in 72e6516
Then when code lenses are updated after a buffer change, it used the new regions to check if it can re-use the previous annotations temporarily until the code lenses get updated with the real data from
codeLens/resolve. But this would only work for the code lenses between the start of the file and the cursor postion (where user is currently typing), because the offset-based regions for the code lenses that come after the cursor position would change after typing or deleting some characters in the file. So in this PR I used the line and column based LSP ranges as keys for the code lens groups instead. If you type some characters on a line, the LSP ranges for the code lenses after that line are still the same, and therefore caching should work for all code lenses in the entire file, except for the exact line where the user is typing and as long as the user didn't type or deleted a linebreak.This rewrite also significantly reduces the number of ST API calls for
add_regionsand for updating phantoms. Now only a single region key per session is used for the code lens annotations, instead of one key per code lens and session. I wonder whether there was a reason that it was implemented as one region key per code lens before?LSP/plugin/code_lens.py
Lines 203 to 205 in 72e6516
Furthermore, if there were no code lenses in the view, and no code lenses need to be added after a buffer change, there is no unnecessary API call anymore to clear annotations and phantoms.
More fixes and changes:
codeLens/resolverequests and notcodeAction/resolve, which is a bug in the current implementation:LSP/plugin/session_buffer.py
Line 831 in 72e6516
Fixes #2497
Fixes #2355