J'ai des fichiers source C ++ dans un référentiel GitHub qui ont une extension de .C et utilisent la coloration syntaxique C, ce que je ne veux pas.
Comment puis-je configurer GitHub pour appliquer la coloration syntaxique C ++ à ces fichiers?
Existe-t-il une méthode permettant à GitHub d'identifier la langue source à des fins de mise en évidence de la syntaxe?
Il semble qu'il utilise uniquement l'extension de fichier, mais existe-t-il un moyen de forcer une langue particulière?
J'ai demandé à [email protected]; voici leur réponse:
Nous utilisons Pygments (http://pygments.org/) pour mettre en évidence la syntaxe et déterminer le lexer à utiliser en fonction de l'extension de chaque fichier. Malheureusement, il ne semble pas qu'il existe un moyen d'obtenir la mise en évidence C ++ sans renommer les fichiers de * .c -> * .cpp et * .h -> * .hpp.
Vous pouvez le faire sans perdre l'historique git d'un fichier en utilisant la
git mvcommande.
La détection de la langue de GitHub est effectuée par le module Linguist , qui est commodément open source. Il repose principalement sur l'extension de fichier pour détecter la langue, bien qu'il puisse être un peu intelligent de détecter des fichiers ambigus (tels que des .hfichiers). Comme vous pouvez le voir dans le fichier de configuration , .cest fermement défini comme un fichier C. Étant donné le nombre de fichiers qui doivent être évalués sur GitHub, l'efficacité est une exigence clé, si au prix d'une certaine précision.
Il semble que les configurations par dépôt aient été exclues par le développeur, donc la seule façon de mettre en évidence la syntaxe des fichiers comme C ++ serait d'utiliser des extensions C ++. Pour conserver ces extensions et les mettre en surbrillance, vous devrez peut-être essayer un autre service ou héberger le code quelque part vous-même.
Mise à jour d'octobre 2014 : GitHub ne s'est pas arrêté, au cours de la dernière année, ils ont introduit des heuristiques de base pour aider à déterminer la langue dans le fichier. Plus spécifique à ces questions, les .cfichiers sont maintenant vérifiés pour voir s'ils sont en C, C ++ ou Objective-C.
La réponse du support GitHub est un peu intéressante, ils utilisent des Pygments pour la surbrillance et le lexer, mais les ensembles de règles sont dans leur propre module Linguist. Que vous souhaiteriez qu'ils connaissent!
Pour les fichiers avec un Shebang , le Shebang est pris en compte lors de la détermination de la langue, mais semble être également pondéré par rapport aux autres jetons . Cela semble être une grosse erreur car le Shebang devrait définir définitivement la langue du fichier. Cela peut entraîner des problèmes de mise en évidence.
Comme solution de contournement, vous pouvez ajouter des jetons factices sous la forme d'un commentaire pour "faire pencher la balance" en faveur de la langue correcte. C'est expérimental mais j'ai eu de la chance avec ça .
Partager ma réponse ici, je l'ai découvert ailleurs sur SO .
J'ai découvert que vous pouvez ajouter une modélisation vim ou emacs conformément au fichier Lisezmoi de Linguist en haut de votre fichier source (malheureusement, requis pour chaque fichier) pour forcer la coloration syntaxique pour Github.com. Sur la base du fichier languages.yml , je pense que vous devez ajouter /* vim: syntax=C++ */à votre fichier source.
Vous pouvez désormais forcer la langue de n'importe quel fichier dans vos référentiels à l'aide des substitutions Linguist . Linguist est la bibliothèque open source qui détecte la langue des fichiers sur github.com.
Pour forcer la .cmise en évidence de vos fichiers à l'aide de la grammaire C ++, vous pouvez ajouter les éléments suivants dans votre .gitattributesfichier:
*.c linguist-language=C++
*.S linguist-language=asmsans succès .....gitattributesligne que vous avez publiée devrait obliger Linguist à reconnaître tous les.Sfichiers comme assemblage. Si cela ne fonctionne pas, je peux jeter un œil au dépôt pour essayer de voir ce qui se passe (avez-vous un lien?).