Vscode-theme-onedark: Correction du thème pour la nouvelle portée dans VSCode 1.9

Je vais travailler dessus dès que possible. Tenez bien tout le monde et désolé pour le dérangement :(

Je viens de sortir une version 1.0.0, elle apporte un support minimal pour la version 1.9.

Certains langages n'ont tout simplement pas un bon support dans VS Code et ne permettent pas une bonne coloration (par exemple Java).

J'ai encore beaucoup de travail devant moi. Je crois que je peux obtenir le même support que j'avais avant la 1.9, certains langages (par exemple Python) sont encore vraiment mauvais pour le moment par rapport à la dernière version. Je suis désolé pour ça, j'y travaille.

Je mettrai à jour ce problème au fur et à mesure que je progresse.

Pour tous ceux qui attendent, je pense que la version 1.1.0 a maintenant la même coloration qu'avant la version 1.9. Vous pouvez simplement mettre à jour sur VSCode Marketplace.

Certains langages ont été améliorés avec les nouvelles portées, comme Ruby et JS/TS, mais si vous trouvez une incohérence, en particulier une qui n'existait pas avant la version 1.9, veuillez le signaler.

Je crois que les seules langues manquantes maintenant sont celles qui dépendent de plugins sur VSCode que je supportais avant la 1.9, comme Rust. Je travaillerai dessus au cours de la semaine et fermerai ce problème lorsqu'ils seront publiés.

Merci pour la patience :)

J'ai trouvé l'incohérence suivante.

Langue : JavaScript

Avant:

Après:

Le problème semble être avec les crochets et le code à l'intérieur.

L'exemple de code est

export default class Definition {
    constructor(def) {
        if (invalidParams(def)) {
            throw new Error('Invalid arguments provided to Lang constructor');
        }

        this.__def = def instanceof Map ? def : new Map(def);
    }

    clone = () => new Definition(new Map(this.__def));

    extend = (def) => {
        if (invalidParams(def)) {
            throw new Error(`extend requires Map`);
        }

        const extendedLang = new Map(this.__def);

        for (const [key, value] of def) {
            extendedLang.set(key, value);
        }

        return new Definition(extendedLang);
    }
}

Merci d'avoir signalé !

Je vais regarder ça ce soir et je reviens vers vous.

Fixé. Je vais attendre jusqu'à ce que le reste du travail soit terminé afin de ne pas inonder les utilisateurs d'une nouvelle version tous les jours (j'ai reçu quelques plaintes à ce sujet dans le passé). Cela sera publié dans la version 1.2.0 .

En comparaison,

Atome:

Code VS :

Le mot-clé constructor ne peut malheureusement pas être sélectionné sans changer les couleurs de nombreux autres éléments ensemble... Les déclarations Const en JS ont également ce même problème, pas de portée unique pour elles. Si VSCode s'améliore un jour, je mettrai à jour la correction de ce problème.

Merci encore d'avoir contribué :)

Merci pour la rapidité d'exécution !

Une question cependant : les déclarations const fonctionnaient correctement avant 1.9 et aussi si vous regardez, la déclaration const dans la boucle for fonctionne correctement. Alors pourquoi pas celui au dessus ?

Les [key, value] à l'intérieur de la boucle for sont des déclarations de variables de tableau , donc VSCode leur fournit des portées uniques, que j'ai utilisées.

La const extendedLang est cependant détectée comme une variable régulière. Comme le montre l'image ci-dessous :

C'est la portée la plus spécifique dont il dispose. Et comme vous pouvez le voir, aucune des autres portées ne le détecte comme une déclaration const . Donc, si je le colorie maintenant, chaque variable sera également rouge.
Lorsque je rencontre ces conflits, je dois faire un choix, donc généralement la portée la plus courante ou la couleur la plus agréable pour les yeux l'emporte. Dans ce cas, les variables sont beaucoup plus courantes et les rendre rouges pour correspondre aux consts entraînerait beaucoup plus de différences par rapport au thème d'origine d'Atom.

Quant à savoir pourquoi cela fonctionnait auparavant, VSCode expose maintenant des portées totalement différentes des versions précédentes, j'avais probablement un moyen de différencier la déclaration de variables des consts dans ce cas.

Vous pouvez voir que les consts et les variables ont maintenant exactement les mêmes portées :

Atom expose une portée constant.other.js afin qu'il puisse fournir une coloration personnalisée.

Merci pour l'explication détaillée !

Pouvez-vous créer une option pour colorer tous les types de variables de manière cohérente ? (en rouge je suppose)

J'essaie de suivre le thème Atom d'aussi près que possible. Atom ne colore pas les variables ( var ou let ), elles sont grises. Alors je vais le garder comme ça.

Atome:

Vous pouvez toujours bifurquer le projet et le personnaliser si vous le souhaitez, il est sous licence MIT :)

Quoi qu'il en soit voici un bug:

code:

import * as styles from './mission.scss';

export default function MissionIcon({ key, title }) {
    return <i class={classnames(
        styles['mission__icon'],
        {
            [styles['mission__icon-letter']]: title.match(A_HEBREW_LETTER),
            [styles['mission__icon-first']]: !key,
        }
    )}>{title}</i>;
}

Merci!

Pouvez-vous fournir un peu plus d'informations? Est-ce un fichier JS ou TS ? Est-ce React ?

Un autre bug :

• accolades et points-virgules en jaune
• décorateur @ en gris
• Coloration incohérente des variables (ou est-ce voulu parce qu'elles "deviennent" des clés ?)
  code:

@connect(
    ({ artists }) => ({ artists }),
    dispatch => bindActionCreators({ getArtists, getArtist, addArtist, editArtist, removeArtist }, dispatch)
)
export default class AdminArtists extends Component {

    componentWillMount = () => {
        this.props.getArtists();
    }

    render = () => {
        console.log(this.props.artists);
        return <div>

        </div>;
    }
}

@akamud C'est JS Réagissez

Je vais créer un nouveau problème pour suivre ces problèmes JS React.

Veuillez utiliser #36 pour suivre cette discussion.

La version 1.2.0 a maintenant le même support pour les plugins qu'avant.

Si vous trouvez une autre incohérence, veuillez créer un nouveau problème.