(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Red alert (#90738)

/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:

• object keys are classified as properties (can be discussed)
• it's not readonly, because it isn't really. To formally declare it as 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:

1. Yes, I see the semantic "overlay" is a bit delayed turning it on and off, so this is very likely what is being experienced

2. 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!