Концы одной строки сохраняются в выводе уценки?

Question

Я редактирую файлы уценки в онлайн-редакторе уценок, копирую их из файла, открытого в Notepad ++, и копирую их обратно в Notepad ++, чтобы сохранить, когда я закончу. Проблема: каждый конец строки в текстовом файле создает конец строки в скомпонованном выводе редактора уценки. Я понимаю, что одиночные строки в уценке должны игнорироваться (кроме особых случаев, таких как блоки кода).

Это проблема, поскольку моей организации требуются текстовые файлы, в том числе файлы уценки, для соблюдения максимальной длины строки из 80 символов. У нас есть фильтры, которые сканируют это, например, когда файлы фиксируются на Git, и помечают строки с избыточной длиной как ошибки.

Если уценка composer не игнорирует конец строки, я должен написать каждый абзац текста одной строкой, что делает невозможным соблюдение ограничения в 80 символов.

К настоящему времени вы, вероятно, кипите, потому что я не сказал , который онлайн-редактор уценок Я использую. Я не сказал, потому что это не имеет значения. Я попробовал три совершенно разных, и все они делают это. В итоге я использовал https://stackedit.io/app#.

Я думал, что это может произойти, потому что Notepad ++ сохраняет каждый конец строки как , а редакторы уценки интерпретируют это как два конца строки. Я попытался настроить Notepad ++ для использования Linux конца строки вместо этого, но это не имело никакого значения.

Answer 1

Это полностью зависит от того, какую реализацию вы используете.

Сохранение концов строк (или обработка мягких разрывов строк как жестких разрывов строк) - это надстройка, которая впервые была популяризирована GitHub. Flavored Markdown с тех пор стал очень распространенный в веб-редакторах Markdown. В родных текстовых редакторах есть инструменты для жесткого переноса строк, но эти инструменты обычно не существуют в веб-формах. Большинство пользователей вводят длинные непрерывные строки в веб-форме. Если пользователь добавляет мягкий разрыв строки, то можно разумно предположить, что пользователь предполагал, что разрыв строки будет существовать там. Таким образом, в вашем браузере вы обнаружите, что большинство реализаций будут включать расширение разрывов строк по умолчанию.

Раньше GitHub Flavored Markdown документировался на страницах справки GitHub и в том факте, что окончания строк были сохранены, были четко задокументированы. Однако, поскольку они переключились на расширенную реализацию Commonmark, это уже не так ясно. В их спецификации c они не перечисляют расширение для разрывов строк, которое предполагает, что они следуют типичному поведению Commonmark. Однако Commonmark spe c очень неясен в отношении разрывов мягкой строки :

Соответствующий синтаксический анализатор может отобразить разрыв мягкой строки в HTML как разрыв строки или в качестве пробела.

Средство рендеринга также может предоставлять возможность рендеринга мягких разрывов строк в виде жестких разрывов строк.

Поэтому, если вы используете реализацию на основе Commonmark, это очень важно знать, какую реализацию вы используете. Некоторые могут использовать значение по умолчанию, отличное от других, а некоторые могут предоставлять другой способ изменения этого значения по умолчанию.

Однако, если вы используете реализацию, основанную на оригинальных правилах на daringfireball.com, то вы, вероятно, можете будьте уверены, что жесткие разрывы строк всегда являются жесткими, а мягкие разрывы строк игнорируются.

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