Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Semantic tokens are too broad

Aperta
#9,467 2 commenti 2 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
csharp, typescript, vscode

Direzione di ricerca

Nell’issue non sono identificati file né test. Inizia tracciando la generazione dei token semantici nell’estensione C# attuale e nel percorso Roslyn LSP, quindi confronta i token emessi con gli scope TextMate che sovrascrivono. Il lavoro è completato quando i tipi predefiniti C# e la punteggiatura delle stringhe mantengono classificazioni distinte e tematizzabili senza perdere l’evidenziazione semantica utile.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Backlog Feature Request

Is your feature request related to a problem? Please describe.

C# semantic tokens are currently too broad, which makes theme authors lose distinctions that are already available from the TextMate grammar.

For example, predefined type keywords such as string are classified as plain semantic keyword. That makes them indistinguishable from access/modifier keywords like public and const in semanticTokenColors.

TextMate has the more precise keyword.type.cs, but semantic highlighting overrides it, so themes cannot keep C# type keywords in an intended type color while leaving normal keywords in a keyword color.

The same happens with strings. The semantic token is string and captures the whole string without any distinction between punctuation (") and the actual string content, while multiple themes (and my personal preference) color " slightly differently. Not sure why the semantic token string is even needed here, since strings are usually well detectable by normal TextMate grammar.

semanticHighlighting disabled:

Image

semanticHighlighting enabled:

Image

.

semanticHighlighting disabled:

Image

semanticHighlighting enabled:

Image

Notice the tradeoff: we either have the desired colors for types or string punctuation, or proper semantics for used class names and other types.

In general, TextMate theme authors invest a lot of time to properly color different types of tokens by their semantic meaning. Semantic tokens are also essential for conveying semantics that a TextMate grammar cannot know, but overly broad semantic tokens hurt because more precise TextMate distinctions are effectively lost.

Disabling semantic tokens is often not an option, as you can see from the examples above.

Describe the solution you would like

The solution, beyond implementing this on the VS Code side (https://github.com/microsoft/vscode/issues/165788), would be to add more precise semantic token classifications, modifiers, or C#-specific semantic token subtypes for cases where the current semantic token is broader than the TextMate scope it replaces.

Examples:

  • C# predefined type aliases such as string, int, bool, etc. should not be only keyword:csharp; possible alternatives could be type.defaultLibrary:csharp, type:csharp, or a C#-specific semantic subtype/modifier that themes can target separately from normal keywords.
  • String punctuation should remain distinguishable, either by not overriding precise TextMate scopes with broad string tokens or by emitting specific semantic token subtypes/modifiers for it.

Semantic tokens should preserve or improve the precision available to themes. They should not carpet-replace precise TextMate classification with a broader semantic one unless there is another way for theme authors to recover that distinction.

Applicable Scenarios

Users and theme authors who need semantic highlighting to stay enabled but still need tokens with different meanings to remain distinct colors.

Describe alternatives you've considered

  • Disabling semantic highlighting for C# works around this, but it throws away useful semantic coloring entirely.
  • Styling keyword:csharp is too broad because it also changes normal C# keywords.
  • Styling string:csharp is too broad because it also changes the whole string, not only string punctuation.
  • VS Code feature request microsoft/vscode#165788 from 2022 would also help by allowing semantic token rules to use TextMate scopes as an extra condition, but that is closed as not planned because it did not gain 20 upvotes. Given the current VS Code theming model, the C# extension can preserve theme control by emitting semantic tokens that are at least as precise as the TextMate scopes they override.

Additional context

Related older issue: dotnet/vscode-csharp#5587. That issue was closed as not planned and labeled OmniSharp, but the same general problem is still visible with the current C# extension / Roslyn LSP path.

Environment where I observed this:

VS Code: 1.116.0
C# extension: 2.140.9
C# Dev Kit: 3.20.199
Roslyn server listed by extension package: 5.7.0-1.26220.12
Using OmniSharp: false / not configured
.NET SDK: 8.0.420
OS: Windows 11, 10.0.26100, win-x64
Theme: any that colors C# types/keywords or string delimiters/content differently
Lingua principale
TypeScript
Stelle
3.1k
Fork
738
Merge medio
19h 24m
PR unite (30g)
48

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnet/vscode-csharp

Tutte le issue di dotnet/vscode-csharp

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.