На нашем форуме мы недавно заметили, что код подсвечивается автоматически, даже если autohighlight all code выключен, а highlighted languages пуст. Мы сделали это, потому что у нас много кода на языках, которые не поддерживаются. Но теперь он определяется как C#.
Пример поста:
Можем ли мы воспроизвести это на следующей неделе @tshenry?
Я могу воспроизвести это на Try. Похоже, что настройка сайта autohighlight_all_code игнорируется. Функциональность, кажется, включена независимо от того, отмечена настройка или нет. Настройка highlighted languages влияет на определение языка, но если всё удалено, при обнаружении чего-либо похожего на код, по умолчанию, кажется, выбирается csharp.
Последнее изменение в ядре, связанное с подсветкой синтаксиса, — это рефакторинг от @j.jaffeux:
завтра посмотрю
Я не думаю, что здесь что-то ухудшилось; в лучшем случае до моих различных исправлений несколько недель назад всё работало некорректно.
Вот что происходит: по умолчанию мы всегда добавляем auto и nohighlight в список допустимых классов для кода. Если вы не указали язык при определении блока кода, будет использоваться значение default_code_lang, которое по умолчанию равно auto. Если вы установите его в nohighlight, вы получите ожидаемый результат. Обратите внимание, что вам потребуется перестроить HTML-верстку постов. Также, скорее всего, вам не нужно очищать highlighted_languages, так как это не окажет эффекта, если выбран nohighlight.
Это происходит с совершенно новыми постами, значит, что-то определённо изменилось.
(И да, я понял, что пустой список языков мне не нужен — у нас иногда встречаются JS и Python, так что лучше разрешить их подсветку, если кто-то добавит код.)
Не работает то, что при снятии флажка «Автоматически подсвечивать весь код» блоки кода без тегов всё равно подсвечиваются автоматически.
Блоки кода с тройными обратными кавычками (```) всегда получают автоматическую подсветку, а вложенные блоки кода ( ) — вот на что влияет эта настройка.
Ох, ну… почему существует разница? И можно ли это изменить?
Что-то изменилось в Discourse, потому что блоки кода с ограждением раньше не подсвечивались автоматически. Наш форум на Discourse существует уже почти два года. До самого последнего обновления блоки кода с ограждением не подсвечивались автоматически.
Можно ли это изменить? Да, настройка «autohighlight all code» делает поведение последовательным для обоих типов блоков кода.
Если вы не хотите автоматического выделения, за исключением случаев, когда язык указан явно,
Да, возможно, но, как я уже сказал, сейчас я не вижу ничего, что работало бы не так, как ожидалось. Поэтому пока я предполагаю, что раньше что-то работало некорректно по ошибке, и вы полагались на это поведение.
Мне кажется, что код определялся как язык, который загружался некорректно, из-за чего блок в итоге не подсвечивался.
Хм, хорошо. Можно ли тогда превратить это в предложение изменить описание (и даже название) настройки «autohighlight all code» на более точное? Возможно, стоит переименовать её в «autohighlight indented code» с описанием: «Применять подсветку синтаксиса к блочным отступным блокам кода, даже если язык явно не указан».
Конечно, не стесняйтесь создавать pull request.
Также я с радостью исправлю проблему, если вы её обнаружите.
Посмотрев в консоль, я тоже заметил что-то подозрительное:
Это не ново, но я считаю, что наше внедрённое значение nohighlight неверно и должно быть no-highlight. Это также подтверждает мою догадку о том, что вы увидели: код был обнаружен, но не найден, и происходил переход к no-highlight. Я внесу это изменение.
Я сделаю PR для изменения описаний.
Остаётся один вопрос: как C# мог быть вариантом, когда список подсвечиваемых языков был пуст? Действует ли пустая настройка так, будто она содержит список по умолчанию?
Да, я тоже об этом задумывался.
Как я понимаю, в этой строке: https://github.com/discourse/discourse/blob/master/app/assets/javascripts/discourse/app/lib/highlight-syntax.js#L42
Когда мы удаляем этот класс и затем просим highlightjs подсветить блок кода, мы больше не полагаемся на markdown, и поскольку это изменение на стороне клиента, ограничения по классам больше не действуют.
Вкратце:
Хм. Это несколько ограничивает его полезность. Я посмотрю, смогу ли я придумать полезное уточнение для описания.
В качестве ещё одного примера: мы используем 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 в композере.