When using a color scheme with significant use of semantic tokens, it becomes very noticible that hover info and other similar features do not include semantic highlighting. For instance, I use a color scheme that makes a color distinction for class/interface/enum, and so usually, I know just by looking at a type which of these it is, however if I look at the type of a variable in a hover popup, this visual information is missing. Sometimes the kind of type it is will be written in text, which may allow coloring the name by syntax in some cases, but generally any documentation examples included in the hover info will lack the usual color information. This is a noticible difference in quality of experience between lsp-based editors and more traditional ides that do their own semantic analysis.
My proposal is to add the ability for clients to advertise that they support semantic tokens in markdown, and for servers to provide semantic tokens with markdown any time they provide markdown.
When using a color scheme with significant use of semantic tokens, it becomes very noticible that hover info and other similar features do not include semantic highlighting. For instance, I use a color scheme that makes a color distinction for class/interface/enum, and so usually, I know just by looking at a type which of these it is, however if I look at the type of a variable in a hover popup, this visual information is missing. Sometimes the kind of type it is will be written in text, which may allow coloring the name by syntax in some cases, but generally any documentation examples included in the hover info will lack the usual color information. This is a noticible difference in quality of experience between lsp-based editors and more traditional ides that do their own semantic analysis.
My proposal is to add the ability for clients to advertise that they support semantic tokens in markdown, and for servers to provide semantic tokens with markdown any time they provide markdown.