Flatten highlights #3447
Labels
Comments
matklad
added
E-medium
E-has-instructions
|
I have had a look at the specific code and I would like to work on it. I am not sure about the semantics of |
|
We need to keep it internally, as this is a useful (and somewhat tricky
with respect to shadowing) feature to have. However, the impl should
probably be changed to a separate request, independent of the main
highlighting.
…On Thu, 2 Apr 2020 at 14:07, Laurențiu Nicola ***@***.***> wrote:
@matklad <https://github.com/matklad> do we still want the rainbow stuff
after #3820 <#3820>?
It's only used in a test.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3447 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANB3MYPS7BRJHSWEBFWJOLRKR5ZHANCNFSM4LBHTOAQ>
.
|
bors bot
added a commit
that referenced
this issue
Apr 8, 2020
3826: Flatten nested highlight ranges during DFS traversal r=matklad a=ltentrup Implements the flattening of nested highlights from #3447. There is a caveat: I needed to add `Clone` to `HighlightedRange` to split highlight ranges ~and the nesting does not appear in the syntax highlighting test (it does appear in the accidental-quadratic test but there it is not checked against a ground-truth)~. I have added a test case for the example mentioned in #3447. Co-authored-by: Leander Tentrup <[email protected]>
|
Did #3826 solve this? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
highlightfunction currently returns aVec<HighlightedRange>. However, those highlighting ranges can be nested. I believe that for something like#[cfg(feature = "foo")]we produce the range for the whole attribute, and then, separately, a range for a string literal.It seems like all the clients of syntax highlighting actually want a flat list of highlights. We should refactor
highlightso that it produces such flat list. One obvious way to do this is to post-process the current return type, but, given that internally we walk the tree in dfs manner, perhaps we can just not produce nested things in the first place?The relevant code is here:
https://github.com/rust-analyzer/rust-analyzer/blob/a5da660bd5953c046db5f0bff854c00d830da9c8/crates/ra_ide/src/syntax_highlighting.rs#L34-L38
The text was updated successfully, but these errors were encountered: