Почему Markdown делает это? (удаление пробелов и другие функции)

[Rhababo]

Приношу извинения за расплывчатый заголовок.

Я в процессе модификации некоторых функций Markdown в Discourse, чтобы они лучше соответствовали потребностям моего сообщества, которое переходит с форума MyBB.

Discourse — это мой первый опыт работы с Markdown, и я хочу придерживаться принципа: «Не сноси забор, если не знаешь, зачем он там стоит». Однако мне трудно понять, почему Markdown выполняет те или иные действия, и я был бы очень признателен за ресурсы, которые помогут мне разобраться (особенно если есть какие-то вопросы безопасности, которые я могу упускать).

Ответ в этой теме предоставил несколько хороших общих ссылок, включая ранние обсуждения и (теперь уже не существующий) плагин:

Rich Text Formatting (WYSIWYG)

Hi all, The users of my Discourse community are sports teachers who are not very technical, therefore the enforced use of markdown in the editor has created some formatting problems in posts. Ideally, we could enable a rich text WYSIWYG editor to make posting as simple and familiar as possible. Are there any ways to enable this or, if not, plans for inclusion on the roadmap? Cheers

А этот пост оказался невероятно полезным с точки зрения разработки:

Developer's guide to Markdown extensions

Discourse uses a Markdown engine called Markdown-it. Here are some dev notes that will help you either fix bugs in core or create your new plugins. The Basics Discourse only contains a few helpers on top of the engine, so the vast majority of learning that needs to be done, is understanding Markdown It. The docs directory contains the current documentation. I strongly recommend reading: The architecture document to understand at a top level how the engine works. Development for basic d…

Но, повторюсь, я хочу понять, почему существуют определённые функции, чтобы я мог лучше оценить необходимость их удаления или настройки.

Вот функции, которые сейчас находятся в фокусе моего внимания:

1. Удаление последовательных переносов строк без тега <br> или другого кода.
2. Автоматическое создание блоков кода на строках с 4 и более ведущими пробелами.
3. Удаление ведущих пробелов на новой строке.
4. Превращение любой последовательности чисел в нумерованный список с последовательным увеличением.

Любая помощь будет очень кстати! Спасибо!

[Canapin (Coin-coin le Canapin)]

Меня очень интересует эта тема, но у меня нет знаний, чтобы ответить на большинство ваших вопросов.

Однако,

@Rhababo

Удаление последовательных переносов строк без тегов </br> или другого кода.

@Rhababo

Удаление начальных пробелов в начале новой строки.

По-моему, Discourse стремится делать посты чистыми и удобными для чтения.
Убирая лишние переносы строк и обрезая пробелы в начале строк, система обеспечивает единообразие внешнего вида постов.
Это особенно помогает, когда пользователи, иногда даже не осознавая этого (я знаю таких!), добавляют случайные пробелы или пустые строки, что может затруднить чтение их контента.

@Rhababo

Преобразование любой последовательности чисел в нумерованный список с последовательным возрастанием.

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

[Jagster (Jakke Flemming)]

@Canapin

строки, которые могут затруднить чтение их содержимого

На самом деле, чрезмерная плотность размещения элементов может затруднить чтение. Например, абзац сразу после изображения.

Но… я использую <br />, так что это не проблема.

Однако ещё один нюанс… Я почти уверен, что операция очистки не имеет никакого отношения к улучшению читаемости. Это особенность самого кода. Похоже на утомлённое утверждение, что Markdown легче читать на «уровне кода». Конечный пользователь никогда не оказывается в такой ситуации.

Что ж. Сейчас это чистая мета-дискуссия.

Но я отказываюсь верить, что удаление пустых строк и лишних пробелов действительно улучшает общий опыт для конечного пользователя.

[simon]

@Rhababo

Удаление последовательных разрывов строк без </br> или другого кода.

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

Вот пример с включённой настройкой:

А вот пример с отключённой настройкой (значение по умолчанию):

@Rhababo

Discourse — это моё первое знакомство с Markdown,

Возможно, стоит заглянуть на эту страницу и попробовать её 10-минутный учебник по Markdown: Markdown Reference. Учебник для новых пользователей в Discourse содержит ссылку на эту страницу, но многие пользователи, проходящие учебник, вероятно, её пропускают:

[Heliosurge (Dan DeMontmorency)]

@Jakke Flemming

Но я отказываюсь верить, что удаление лишних строк и пробелов действительно улучшает общий опыт для конечного пользователя.

Это точно превращает ASCII-арт в вызов для правильного отображения.

[Rhababo]

@Canapin

Я думаю, что Discourse стремится делать посты чистыми и удобными для чтения.
Удаляя лишние переносы строк и обрезая пробелы в начале строк, он обеспечивает единообразие внешнего вида постов.

@Canapin

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

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

@simon

Возможно, стоит заглянуть на эту страницу и попробовать 10-минутный учебник по Markdown: Справочник по Markdown.

Это очень полезный учебник, и его акцент на «создании красивого текста» действительно согласуется с ранее упомянутыми идеями о единообразии. Спасибо, что указали на него.

[Rhababo]

Читая дополнительную информацию о Markdown, я обнаружил этот сайт, который оказался особенно познавательным.

Я считаю, что это оригинальное описание Markdown, на которое ссылается команда CommonMark, и оно показывает, что одна из ключевых причин того, как работает Markdown, заключается в его близости к HTML.

Например, первое предложение там гласит:

Markdown — это инструмент преобразования текста в HTML для веб-авторов.

Мне кажется, что некоторые странности Markdown обусловлены не столько его организационными свойствами, сколько стремлением аккуратно преобразовывать текст в соответствующий HTML-код.

Это объясняет, почему пробельные символы обрезаются: ведь HTML сам обрезает пробелы.

Также становится понятнее, почему любая последовательность чисел превращается в нумерованный список с возрастающими номерами, если обратиться к этому разделу:

Lists - Daring Fireball: Markdown Syntax Documentation

@https://daringfireball.net/projects/markdown/syntax#list

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

<ol>
<li>Птица</li>
<li>МакХейл</li>
<li>Пэриш</li>
</ol>

Если вы напишете список в Markdown следующим образом:

1.  Птица
1.  МакХейл
1.  Пэриш

или даже так:

3. Птица
1. МакХейл
8. Пэриш

вы получите точно такой же HTML-вывод. Суть в том, что если хотите, вы можете использовать порядковые номера в своих нумерованных списках Markdown, чтобы числа в исходном тексте совпадали с числами в опубликованном HTML. Но если вам лень, это не обязательно.

Таким образом, Markdown даже не обращает внимания на числа, потому что нумерованные списки в HTML не занимаются присвоением номеров. (Код в markdown-it действительно проверяет символ в первой позиции, но только для того, чтобы начать нумерацию с этого символа).

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