Готовим на C++

Разработка
1

(Первый пост, так что будьте терпимы…)

Недавно я настроил собственный форум на Discourse: https://crucible.hubbe.net/. В основном я очень доволен им. Сообщество посвящено плате типа Arduino, которая используется в основном создателями реквизита. В связи с этим мы часто используем шаблонный код на C++. В частности, мы применяем нечто, называемое «стилем» (style), который конфигурирует отображение света. Стили могут быть сложными, поэтому я написал онлайн-предпросмотрщик/редактор, а затем использовал тему-компонент discourse-linkify, чтобы стили автоматически становились ссылками на редактор. Мне пришлось внести небольшие изменения в компонент темы discourse-linkify, чтобы правильно экранировать символы URL и прочее, что было несложно, и я могу создать pull request с этими изменениями, если это будет интересно.

Результат можно увидеть здесь: StylePtr links - The Crucible - The Crucible

Однако есть проблема…
Некоторый шаблонный код из-за множества символов < и > выглядит немного как HTML, и в какой-то момент Discourse удаляет некоторые из этих «тегов». По сути, похоже, что любое неизвестное слово, заключённое в < >, удаляется. Следующая строка в этом сообщении будет , но без пробелов:

< - здесь находится foo

Сначала я думал, что проблема в компоненте linkify, но после некоторых исследований выяснилось, что недостающие части уже исчезли к моменту запуска linkify. Так что, похоже, лишние теги испарились где-то в процессе обработки?

Я заметил, что в блоках кода (с тройными обратными кавычками и аналогичными) теги сохраняются, но для моих целей было бы лучше, если бы они всегда сохранялись.

В течение какого-то времени я думал, что достаточно будет изменить CODE_BLOCKS_REGEXP в файле discourse/lib/utilities.cs, чтобы это работало, но inCodeBlock используется не из многих мест, так что, возможно, это неверный подход? Кроме того, я пока не разобрался, как именно модифицировать CODE_BLOCKS_REGEXP из плагина или компонента темы.

Какой код на самом деле отвечает за удаление этих тегов?
Какой лучший (наиболее поддерживаемый) способ отключить это?

2

Стоит также отметить, что, поскольку люди иногда вставляют большие блоки кода, бывает очень сложно заметить, что какая-то часть посередине пропала. По крайней мере, было бы лучше, если бы неизвестные теги превращались в мигающие предупреждающие знаки или что-то ещё, что давало бы пользователю понять, что произошло что-то неожиданное.

3

Вопрос: почему бы не попробовать использовать блоки кода Markdown?

Просто заключите ваш код в тройные обратные кавычки: ` символ.

Как это:

here 
<foo>
is <some> </fooer> </foo>

А это исходный Markdown моего поста: https://meta.discourse.org/raw/187974/3

Вам придётся обучать пользователей, но это ваша работа как модератора, плюс это поможет всем пользователям, которым в дальнейшем придётся иметь дело с Markdown.

Вы можете сделать это, создав новую закрепленную глобальную тему, например, «Как встраивать код на этом сайте» или «Как печатать на этом сайте».

Также вы можете направить их по этой ссылке: Справочник по Markdown (commonmark.org)

4

Хорошо, я просто хотел оставить эту ссылку здесь на случай, если у кого-то ещё возникнет та же проблема.

Кажется, что добавление обратных кавычек и ссылки по тому же шаблону, который использует плагин piratize, решит эту задачу.

5

Потому что у меня есть дела поважнее, чем гоняться за котами?
Если есть лёгкий и правильный способ что-то сделать, люди всегда выберут лёгкий путь. Я полагаю, что если бы я мог реально запретить пользователям размещать шаблоны StylePtr<> вне предварительно отформатированного текста, то их заставили бы делать всё правильно. Но как это сделать? (Кроме того, это кажется слишком радикальным решением, так как это может также заблокировать совершенно легитимные способы обсуждения шаблонов StylePtr<>.)

Мое текущее решение для создания ссылок на шаблоны StylePtr<> с помощью linkify тоже не работает в предварительно отформатированном тексте, поскольку DOM там сильно отличается, но это небольшая проблема, которую я, вероятно, смогу исправить с помощью небольшой доработки кода.

Возможно. Думаю, я бы использовал этот паттерн для автоматического добавления обратных кавычек, если их нет, а затем применил бы обратный вызов после обработки поста для создания ссылок. Если я не ошибаюсь, иначе нет способа добавить ссылку посередине предварительно отформатированного текста.

6

Лучшее решение — побуждать пользователей использовать обратные кавычки для встроенного кода и три обратные кавычки для блоков кода. Может быть, создать закрепленную тему об этом на вашем форуме?

Кроме того, вы можете попробовать Unformatted Code Detector.

7

Компонент темы детектора неформатированного кода выглядит многообещающе.
Тогда мне останется только создать компонент темы, который обрабатывает ссылки внутри предварительно отформатированного кода, что я и планировал сделать в любом случае. Я обязательно попробую это.

8

Оказывается, мне нужно было просто включить поддержку многострочных регулярных выражений в модуле linkify, чтобы он работал так, как я хотел. Так что, думаю, всё в порядке, если только люди действительно будут обращать внимание на детектор неформатированного кода.