Synxtax color entity.name.type not validated for [type] over storage.type scope
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 42/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- À l'abandon
- Stack technique
- powershell
- Domaine
- tooling
Piste de recherche
Start by reviewing powershell.tmLanguage.json and reproducing the reported [string] type and function statement in VS Code with the listed tokenColorCustomization settings. Compare the scopes assigned to each construct with the expected PowerShell ISE colors; done means the type and statement can be distinguished as described, with focused validation for the grammar change.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Environment
-
Editor and Version:
Visual Studio Code
Version: 1.35.0 (system setup)
Commit: 553cfb2c2205db5f15f3ee8395bbd5cf066d357d
Date: 2019-06-04T01:18:19.664Z
Electron: 3.1.8
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT ia32 10.0.17763 -
Your primary theme: PowerShell ISE
Issue Description
The entity.name.type is not validated over storage.type when defined in settings.json nor in theme.json.
When defining a type, i.e. [string], and using a statement, i.e. function, they both use the same syntax color from the storage.type scope.
Is the entity.name.type scope not defined for types?
Screenshots
Example code. Pasted the tokenColorCustomization from Settings.json in the same file for example purposes.

[string] type

function statement

Expected Behavior
In PowerShell ISE the statements uses the Keyword token with color '#00008b' and the types uses the Type token with color '#008080'. Is there another way to distinguish these scopes or tokens that I've missed or is the powershell.tmLanguage.json missing something?
- Langage dominant
- PowerShell
- Étoiles
- 151
- Forks
- 55
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de PowerShell/EditorSyntax
-
Difficulté 3/5 1-2 jours Accessibilité débutants 55/100
PowerShell/EditorSyntax#224 · 2 commentaires ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 48/100
PowerShell/EditorSyntax#222 · 2 commentaires ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 55/100
PowerShell/EditorSyntax#221 · 2 commentaires ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 45/100
PowerShell/EditorSyntax#220 · 2 commentaires · 1 réaction ·
-
Issue-Bug
Difficulté 3/5 1-2 jours Accessibilité débutants 48/100
PowerShell/EditorSyntax#219 · 2 commentaires ·
Toutes les issues de PowerShell/EditorSyntax
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
nightscout/nocturne#1424 ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Ouvertearea: repo bug perceived difficulty: 2
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
-
impl detach for native Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
paritytech/zombienet-sdk#591 ·
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
mruangutai/harness#1897 ·