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
This LSP request sends a cursor position and expects a list of ranges to be returned that should be highlighted. Usually, LSPs return highlights that correspond to the items semantically equal to the item at the cursor. VsCode sends the textDocument/highlight request every time the cursor moves. If an LSP does not implement this request, by default VsCode will highlight all words in the file that are the same as the word under the cursor. This PR improves on this default behavior by:
Disabling this feature in irrelevant contexts (such as comments and string literals)
Disabling this for keywords
Taking into account Rocq's lexical analysis
I similarly disabled hover and jump to definition in irrelevant contexts (you were able to jump to definition/hover on things in prose of comments and string literals!).
Nr. 3 means that we now properly see e and e' as two different tokens. The default vscode behavior led to the very annoying highlight of unrelated identifiers:
Now, things are properly distinguished:
As future work, it would be better to extend highlight to actual semantic reasoning, not only syntactic.
Thanks, it looks interesting.
I think there is still a flaw in the sense that let e := ... in let e := ... in e would not properly handle shadowing, but for that one needs a data that is not available yet, the so called glob_term.
I wonder if we could, one day, provide more info, like the type of the selected expression.
I think there is still a flaw in the sense that let e := ... in let e := ... in e would not properly handle shadowing
Yeah, we could try to syntactically differentiate those two es, but that would replicate a lot of logic which would be better to get from some semantic information about these es anyway. I see the current implementation as an incremental improvement over VsCode's default behavior (which would fail here too).
the so called glob_term.
What is that and how would it improve the situation?
Rocq does a few passes on the ast, and glob_terms do most of the work about binders & co.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This LSP request sends a cursor position and expects a list of ranges to be returned that should be highlighted. Usually, LSPs return highlights that correspond to the items semantically equal to the item at the cursor. VsCode sends the
textDocument/highlightrequest every time the cursor moves. If an LSP does not implement this request, by default VsCode will highlight all words in the file that are the same as the word under the cursor. This PR improves on this default behavior by:I similarly disabled hover and jump to definition in irrelevant contexts (you were able to jump to definition/hover on things in prose of comments and string literals!).
Nr. 3 means that we now properly see

eande'as two different tokens. The default vscode behavior led to the very annoying highlight of unrelated identifiers:Now, things are properly distinguished:
As future work, it would be better to extend highlight to actual semantic reasoning, not only syntactic.