Sur notre forum, nous avons récemment remarqué que le code est mis en surbrillance automatiquement, même si autohighlight all code est désactivé et que highlighted languages est vide. Nous avons fait cela parce que nous avons beaucoup de code dans des langages non pris en charge. Mais maintenant, ils sont détectés comme du C#.
Exemple de publication :
Peut-on reproduire cela la semaine prochaine, @tshenry ?
Je peux reproduire le problème sur Try. Il semble que le paramètre de site autohighlight_all_code ne soit pas respecté. La fonctionnalité semble être activée, que le paramètre soit coché ou non. Le paramètre highlighted languages affecte la détection des langages, mais si tout est supprimé, il semble que cela par défaut à csharp lorsqu’il détecte du code.
La dernière modification du noyau impliquant la coloration syntaxique semble être le refactor de @j.jaffeux :
Je regarderai demain
Je ne pense pas qu’il y ait eu de régression ici. Au mieux, cela fonctionnait incorrectement avant que je n’apporte mes diverses corrections il y a quelques semaines.
Voici ce qui se passe : par défaut, nous ajoutons toujours auto et nohighlight à la liste des classes de code acceptables. Si vous ne définissez aucun langage lors de la création de votre bloc de code, il utilisera la valeur de default_code_lang, qui est par défaut auto. Si vous la définissez sur nohighlight, vous devriez obtenir le résultat attendu. Notez que vous devrez reconstruire le HTML des publications. Vous n’avez probablement pas non plus besoin de vider highlighted_languages, cela n’a aucun effet si vous choisissez nohighlight.
Cela se produit pour des publications entièrement nouvelles, donc quelque chose a définitivement changé.
(Et oui, j’ai réalisé que je n’ai pas besoin d’une liste de langues vide ; nous recevons parfois du JavaScript et du Python, alors autant les mettre en surbrillance si quelqu’un ajoute du code.)
Ce qui ne fonctionne pas, c’est que lorsque l’option « surligner automatiquement tout le code » n’est pas sélectionnée, les blocs de code non étiquetés sont tout de même surlignés automatiquement.
Non, ce n’est pas le cas. Et ce n’est pas non plus le bug que vous avez signalé dans le message principal.
Les blocs de code délimités par des accents graves (```) bénéficient toujours de la coloration syntaxique automatique, tandis que les blocs de code indentés (<code> </code>) sont ceux sur lesquels ce paramètre agit.
Oh… Pourquoi y a-t-il une différence ? Et est-ce que cela peut être modifié ?
Quelque chose a été changé dans Discourse, car les blocs de code délimités n’étaient pas automatiquement surlignés auparavant. Nous avons notre forum Discourse depuis presque deux ans maintenant. Jusqu’à la mise à jour la plus récente, les blocs de code délimités n’étaient pas automatiquement surlignés.
Cela peut-il être modifié ? Oui, le paramètre « autohighlight all code » rend le comportement cohérent pour les deux types de blocs de code.
Si vous ne souhaitez jamais d’auto-surlignage sauf lorsqu’une langue est explicitement spécifiée,
Oui, peut-être, mais comme je l’ai dit, je ne vois rien qui ne fonctionne pas comme prévu actuellement. Mon hypothèse est donc qu’il y avait auparavant un dysfonctionnement involontaire, et que vous vous appuyiez sur ce comportement.
Je pense que le langage a été détecté mais ne s’est pas chargé correctement, ce qui a empêché le bloc d’être surligné.
Hmm, d’accord. Pourrions-nous donc en faire une demande afin que la description (et même le nom) du paramètre « autohighlight all code » soit rendue plus précise ? Serait-il possible de le modifier en « autohighlight indented code » avec la description « Appliquer la coloration syntaxique aux blocs de code indentés, même lorsqu’ils ne spécifient pas explicitement le langage. » ?
Bien sûr, n’hésitez pas à soumettre une PR.
Je suis également ravi de corriger un problème si vous en trouvez un.
En regardant ma console, j’ai aussi remarqué quelque chose de suspect :
Ce n’est toujours pas nouveau, mais je pense que notre valeur injectée de nohighlight est incorrecte et devrait être no-highlight. Cela renforce également mon hypothèse selon laquelle ce que vous avez vu détecté comme du code, qui n’a pas pu être trouvé, a basculé vers no-highlight. Je vais apporter la modification.
Je vais faire une PR pour modifier les descriptions.
Une question persiste : comment csharp était-il une option alors que les langues mises en évidence étaient vides ? Une configuration vide agit-elle comme si elle contenait la liste par défaut ?
Oui, je me posais la même question.
À ma connaissance, à cette ligne : https://github.com/discourse/discourse/blob/master/app/assets/javascripts/discourse/app/lib/highlight-syntax.js#L42
Lorsque nous supprimons cette classe et demandons ensuite à highlightjs de surligner le bloc de code, nous ne dépendons plus du markdown. Il s’agit d’une modification côté client, donc les limitations liées aux classes ne s’appliquent plus.
En résumé :
Hé bien. Cela limite un peu son utilité. Je vais voir si je peux proposer une précision utile pour la description.
Pour ajouter un autre point de données, nous utilisons text par défaut, qui est un alias pour nohighlight, et nous en avons tiré de bons résultats.
Nous avons remarqué quelques bugs de temps en temps, mais globalement, c’est la meilleure approche pour nous, et cela donne un meilleur rendu avec raw, par exemple :
```text
jtl_name=$(/usr/local/bin/kubectl exec -it --namespace=$namespace $master_pod -- bash -c "ls -tr /*.jtl" | awk '{sub(/\r$/, ""); print}')
```
Ce qui produit :
jtl_name=$(/usr/local/bin/kubectl exec -it --namespace=$namespace $master_pod -- bash -c "ls -tr /*.jtl" | awk '{sub(/\r$/, ""); print}')
Nous avons également une icône personnalisée pour le bloc de code délimité par défaut text dans l’éditeur.