Semantic tokens are too broad
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
- Ambito
- developer-experience, tooling
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
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:
semanticHighlighting enabled:
.
semanticHighlighting disabled:
semanticHighlighting enabled:
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 onlykeyword:csharp; possible alternatives could betype.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
stringtokens 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:csharpis too broad because it also changes normal C# keywords. - Styling
string:csharpis 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
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di dotnet/vscode-csharp
-
Infrastructure Test
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
dotnet/vscode-csharp#9791 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Debugger untriaged
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
dotnet/vscode-csharp#9838 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
False Razor diagnostics on historical file in Git diff editorForse già presa @davidwengier l’ha presa oggi. ApertaC#DK Razor untriaged
dotnet/vscode-csharp#9831 · 2 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
C# crashApertaBug C#DK Needs More Info Reliability Remote Extensions Roslyn LSP
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
dotnet/vscode-csharp#9807 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Editor-Formatting Resolved-Configuration Issue
Difficoltà 3/5 1-2 giorni Idoneità per principianti 65/100
dotnet/vscode-csharp#9804 · 6 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di dotnet/vscode-csharp
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
automated issue report
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 68/100
-
documentation
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
github/copilot-sdk#2804 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
drizzle-team/drizzle-orm#6418 ·
I maintainer di solito rispondono entro 4 giorni
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
diegosouzapw/OmniRoute#15307 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni