当フォーラムで、最近気づいたのですが、autohighlight all codeが無効でhighlighted languagesが空であるにもかかわらず、コードが自動的にハイライトされています。これは、サポートされていない言語のコードが大量にあるために行いました。しかし、現在それらがC#として検出されています。
投稿例:
「いいね！」 2
来週これを再現できますか、@tshenry？
「いいね！」 2
Try 環境で再現を確認しました。autohighlight_all_code サイト設定が反映されていないようです。設定がチェックされていてもチェックされていなくても、機能が有効になっているように見えます。highlighted languages 設定は言語検出に影響しますが、すべて削除すると、コードらしきものが検出された場合に csharp がデフォルトとして適用されるようです。
構文ハイライトに関連する最新のコア変更は、@j.jaffeux 氏によるリファクタリングのようです。
「いいね！」 1
明日確認します
「いいね！」 3
ここで何かが後退したとは考えられません。せいぜい、数週間前に私がいくつかの修正を加える前は、正しく動作していなかったということです。
ここで起きていることは、デフォルトでは常に auto と nohighlight を受け入れ可能なコードクラスのリストに追加していることです。コードブロックを定義する際に言語を指定しない場合、default_code_lang の値が使用されます。デフォルトでは auto になっていますが、これを nohighlight に設定すれば、期待通りの結果が得られるはずです。なお、投稿の HTML を再構築する必要があります。また、highlighted_languages を空にする必要はないでしょう。nohighlight を選択している場合、それは効果を持ちません。
「いいね！」 4
これは新しい投稿で発生しているため、何かが確実に変更されました。
（はい、空の言語リストは不要だと気づきました。JS や Python のコードが時折投稿されるので、誰かがコードを追加した場合はハイライト表示されるようにしておきましょう。）
問題となっているのは、「すべてのコードを自動ハイライト」が選択されていない場合でも、タグ付けされていないコードブロックが自動ハイライトされてしまうことです。
ファンスコードブロック（```）は常に自動ハイライトされますが、インデント付きコードブロック（ ）がその設定の影響を受けます。
「いいね！」 2
おお、なるほど。では、なぜ違いがあるのでしょうか？そして、それは変更可能でしょうか？
Discourse 側で何かが変更されたようです。以前は、囲みコードブロックが自動的にハイライトされませんでした。Discourse フォーラムを開設してほぼ2年が経ちますが、最新のアップデートまで、囲みコードブロックの自動ハイライトは行われていませんでした。
変更は可能ですか？はい、「すべてのコードを自動ハイライト」設定により、両方のコードブロックタイプで動作を一貫させることができます。
言語が明示的に指定された場合のみ自動ハイライトを有効にしたい場合は、
もしかしたらその通りかもしれませんが、前述の通り、現在は何も期待通りに動作していない箇所は見当たりません。したがって、これまでの推測では、以前はエラーにより何かが正常に動作しておらず、その挙動に依存していたのではないかと思われます。
おそらく、正しく読み込まれない言語として検出され、結果としてブロック内でハイライトされなかったのだと思います。
「いいね！」 2
ふむ、わかりました。では、この「自動ですべてのコードをハイライトする」という設定の名前と説明をより正確なものに変更するよう要望として提出することはできますか？名前を「自動でインデントされたコードをハイライトする」に、説明を「言語を明示的に指定していなくても、インデントされたコードブロックに対してコードハイライトを適用する」に変更することは可能でしょうか？
「いいね！」 1
もちろん、PR を作成してください。
また、問題を見つけた場合は喜んで修正します。
「いいね！」 2
コンソールを見ると、私も怪しいものを見つけました：
これは新しいことではありませんが、私が注入した nohighlight の値が誤っており、no-highlight であるべきだと考えられます。これにより、あなたが検出したコードが見つからず、no-highlight にフォールバックしていたという私の推測がさらに裏付けられます。変更を行います。
「いいね！」 3
説明文を変更する PR を作成します。
一つ疑問が残ります：ハイライト対象言語が空だった場合、なぜ csharp が選択肢として表示されたのでしょうか？空の設定は、デフォルトのリストが指定されているのと同じように動作するのでしょうか？
「いいね！」 1
はい、私も同じことを疑問に思っていました。
このクラスを削除し、その後 highlightjs にコードブロックをハイライトさせる場合、もはや Markdown に依存せず、これはクライアントサイドの変更であるため、クラスの制限は適用されなくなります。
つまり：
- not auto → 生成されたマークアップに、highlightjs が使用するリストからクラスを追加します
- auto → 生成されたマークアップに lang-auto を追加し、実行時にこれを削除して、highlightjs にハイライトの決定を任せます
ふむ、それではその有用性が少し制限されてしまいますね。説明に役立つ補足ができるか検討してみます。
別の事例として、私たちはデフォルトとして text を使用しています。これは nohighlight のエイリアスであり、これで良好な結果を得ています。
時折いくつかの不具合に気づくこともありますが、全体としてはこれが私たちにとって最善のアプローチであり、例えば raw よりも見た目が優れています：
```text
jtl_name=$(/usr/local/bin/kubectl exec -it --namespace=$namespace $master_pod -- bash -c "ls -tr /*.jtl" | awk '{sub(/\r$/, ""); print}')
```
結果は以下のようになります：
jtl_name=$(/usr/local/bin/kubectl exec -it --namespace=$namespace $master_pod -- bash -c "ls -tr /*.jtl" | awk '{sub(/\r$/, ""); print}')
また、コンポーザー内でも、デフォルトの text フenced コードブロック用のカスタムアイコンを設定しています。
「いいね！」 4