Closed christianalfoni closed 4 years ago
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:
/needsMoreInfo
Could you provide screenshot?
What version do you use?
Is it reproducible with all extensions disabled?
You can try this with F1 and >Developer: Reload Window With Extensions Disabled
I see no difference in highlight (VS Code Insiders)
Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our issue reporting guidelines. Please take the time to review these and update the issue.
Happy Coding!
Hi there and thanks for the quick response!
I think I might have been confused by how the different themes does the highlighting. For example:
This is Dracula Soft without the semanticHighlighting
:
And this happens when I add the semanticHighlighting
:
Though, with Monokai Dimmed, the complete opposite happens. This is without semanticHighlighting
:
And this is with semanticHighlighting
:
Though this theme seems to color all properties the same way, they do not differentiate "constant" properties from normal properties.
Btw, I messed around with the config a bit:
"editor.tokenColorCustomizationsExperimental": {
"property": {
"foreground": "#f51b00"
}
}
Which results in this strange behaviour:
The underlying theme comes through on RED500
there
It looks to me that:
<dict>
<key>name</key>
<string>User-defined constant</string>
<key>scope</key>
<string>constant.character, constant.other</string>
<key>settings</key>
<dict>
<key>foreground</key>
<string>#be9af0</string>
</dict>
</dict>
User defined constants breaks? Maybe there is no term for that in the semanticHighlighting
?
/cc @aeschli
Strange, if you use RED500 (or RED200) there is an extra token
Unfortunately after couple of tests this token dissapeared.
Ah, look there, yeah... but it seems to me that semanticHighlighting
does not support differentiating a property from a constant property then?
If not, then that would indeed be my feature request 😄
@christianalfoni How do you decide it a constant property? Because it is all uppercase?
I don't see any bugs with the example provided. When I try is, all X in colors.X
get the same classification (property). Maybe this is right after editing and semantic highlighting has not yet been applied (I think that what @IllusionMH sees in his example)?
Can you also use the inspect tool?
The difference to syntax highlighting is:
readonly
, you could define an interface where all the properties are marked as readonly
:Here I see that we lack a rule to associate property.readonly
to variable.other.constant.property
. I will add that.
@aeschli Hi there!
Ah, this is great. Cause:
Yes, I see the semantic "overlay" is a bit delayed turning it on and off, so this is very likely what is being experienced
Adding readonly
will actually fix the issue related to the library I work on, so that is supergreat!
And yeah, constant
is meant as all uppercase :-)
Do you still see RED_500
not highlighted? Is it always reproducible?
Oh, is this already released? Or how would I approach testing it?
It's in the latest insiders.
This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!
Hi there!
Very sorry for my late reply, but I found time to check this now and it works! Great 😄 👍 Thanks for looking into this!
With the following code:
We get the following behaviour with the
semanticHighlighting
highlighting:I would expect colors.RED_500 to be highlighted just like the two other properties.
This could maybe be considered a bug, but it could also be considered a lacking feature 😄