Комментарии 92
Кажется это аналог TeX?
Совсем нет. Но TeX можно использовать внутри включения, вставляя формулы.
Всегда удивлялся этому markdown. Урезанные возможности, на каждом сайте markdown свой (на GitHub он отличается от Хабра).
Ну почему бы не взять TeX, благо есть и расширения, которые можно прикрутить к сайту?
Зачем обязательно изобретать свой велосипед на костылях?
В текс могут не только лишь все. Мне лично интеллекта не хватает.
TeX и его расширения (LaTeX) очень, очень, очень многословен. В бытность студентом и аспирантом писал диплом и пару статей в LaTeX-е, вот это было испытание! Но мне было просто интересно и любопытно, хотелось приобщиться к научному сообществу. Сейчас markdown закрывает все мои потребности. В нём есть всё, что нужно для написания хорошей документации на ПО или изделие. Осталось только добавить рендер markdown во все браузеры. Решительно не понимаю, почему этого еще не сделано.
очень, очень, очень многословен.
Можете привести пример?
Пожалуйста: https://mally.stanford.edu/~sr/computing/latex-example.html
LaTeX - write-only language. Попробуйте вычленить глазами полезный текст из кода.
К этому еще следует добавить, что перед тем как писать на LaTeX-е необходимо создать свои шаблоны или адаптировать имеющиеся, что уже само по себе препятствие.
Это точно. Проблема даже не в количестве символов, а то, что для разметки активно используются буквы, которые визуально перемешиваются в кашу, как в регулярных выражениях и человеку приходится прилагать дополнительные усилия для прочтения.
Название стоит особняком - оно выделяется звёздочками, что интуитивно пересекается с выделением жирным.
На выходе это жирный текст или заголовок? Вы бы хоть картинку добавили с тем как это рендерится, а то я запутался в этих звёздочках-чёрточках.
Вот полное описание заголовков: https://markvan.mudrium.ru/markvan-razmetka/bazovye_pravila/zagolovki.html Вот пример markvan-html-рендер барузера https://markvan.mudrium.ru/markvan-razmetka.html И вот здесь демка, можно побаловаться https://markvan.mudrium.ru/demo.html
А где анализ, чем какой-нибудь AsciiDoc не подошел? Или я где-то в посте чего-то не заметил?
AsciiDoc придуман в качестве более лёгкой замены html. У марквана несколько иной путь, строго фиксация структуры текста без оформительских штук, слово семантика не подходит, но что-то близкое пока на ум не приходит. Кстати, тот же markdown тоже имеет расширенный синтаксис Multimarkdown, но тоже не подошёл.
Не очень убедительно.
Надо так:
В AsciiDoc это вот выглядит так (или этого нет), у нас - так.
В (другой язык разметки) так, у нас - так.
И далее по списку из существующих распространенных.
Не, неохота сравнивать. Да и незачем, т.к. эти стандарты немного о другом и пересекаются лишь частично.
Так вот как раз для того, чтобы показать, что 'стандарты немного о другом и пересекаются лишь частично'.
Я человек очень ленивый :) Если кому интересно, он сам сравнит исходя из собственных задач, может ему как раз асции лучше подходит. Пока маркван не опробован на нескольких разнородных проектах и не "устоялся", я не имею морального права как-то за него агитировать. Ну вот такой интересный дизайн получился - посмотрите, но не более. По обычной разметке плюс-минус можно провести параллели с маркдоуном, но вот ``включения`` уже добавляют оригинальности ( возможно). Ну и, если интересно, гляньте таблицы: https://markvan.mudrium.ru/markvan-razmetka/bazovye_pravila/opisanie_vkljuchenij.html#table (Таблица отображается построчно, каждая ячейка в своей строке). Подсмотрел у кого-то идею, может даже на Хабре, но малость подразвил.
Многие знакомы с markdown-разметкой, которая позволяет подготавливать небольшие простые тексты для последующей конвертации в html. […] Другая причина — практические неудобства при подготовке публикаций для интернета. Html возможно хорош для машин, но обычному человеку сложно. Теги "лезут в глаза" и не дают сосредоточиться на содержимом.
Это не случайно, что markdown и HTML поделили разметку. Всякие комментарии — markdown, остальное — HTML. Потому, что интуитивность маркдауна, которую (может быть) не могут обеспечить теги, исчезает, как только нам надо что-то за пределами простых ссылок и ЖК. (Даже не ЖКЧ! Попробуйте подчеркнуть что-то в маркдауне и увидите, к чему приведёт интуиция). Даже такая простая вещь, как картинка, в маркдауне уже означает конец всякой интуитивности и логики. А как только нужен хотя бы спойлер, тут уж приходится лезть в справку или позорно переключаться на WYSIWYG.
В общем, не думаю, что можно сделать одновременно интуитивную и более-менее универсальную разметку (а именно такая нужна для «больших» документов).
Про маркдаун полностью согласен. А про то, что нельзя интуитивную и универсальную, тут не соглашусь, т.к. уже что-то рабочее получилось, нужно только дошлифовать. Ну и и html ещё затрагивает верстку станицы (header, main и .п.) А маркван только про голый текст без окружения.
Даже если маркдаун кажется многим неинтуитивным, как может быть интуитивным более сложный язык той же направленности? Боюсь, это нерешаемая задача.
Покажу на примере. Если меня спросить, как вставлять картинку наиболее интуитивным образом, я отвечу следующее. Синтаксис должен быть аналогичен ссылке, а чтобы не было disambiguity между ссылками и картинками, надо префикс Image:. То есть, например, так:
[Image:Схема сердца.jpg](1. Левая общая сонная артерия. 2. Левая аортная подключичная артерия. 3. Аорта. 4. Левые лёгочные артерии. и т.д.)
После чего текст в круглых скобках превращается в title.
И это мы ещё не трогаем вопросы scope картинок (в HTML он проработан).
Теперь смотрим в спеку, и видим…
[[ Схема строения сердца
>Схема сердца.jpg
]] 1. Левая общая сонная артерия. 2. Левая аортная подключичная артерия. 3. Аорта. 4. Левые лёгочные артерии. и т.д.
Я не буду критиковать её по существу (title или не задан вообще, или задан крайне неудачно отсутствием переноса). Я просто констатирую, что интуиция драматически не совпала. (Да и как может быть иначе, если по мере рассмотрения каждого синтаксического элемента число совпавших интуиций будет экспоненциально сокращаться). Как результат, я уже через пять минут забыл, как тут вставлять картинки.
На больших документах HTML будет самым интуитивным решением, либо, как вариант, старый добрый BB-code, который тот же HTML, но с чётко прописанной границей.
Чтобы яснее видеть всю картину, нужно абстрагироваться от ваших знаний html, которые есть не у всех. Markvan не для html, который лишь один из частных случаев конвертации.
Вот чуть расширю пример добавлением описания картинки
[[ Схема строения сердца
example.com/heart_structure.jpg (Схема сердца)
]] 1. Левая общая сонная артерия. 2. Левая аортная подключичная артерия...В реальной жизни картинка занимает больше места, чем одна строчка, здесь тоже визуально она обособляется от всего текста. Глаз легко вычленяет и название и саму ссылку и описание. И даже не нужно указывать, что это image.
К тому же это ``занимает больше места`` компенсируется ещё и универсальностью подхода и видения текст-нетекст.
Т.е. это не хуже, а просто по другому.
Про указание альтернативных путей для изображения или множественность, тоже есть мысли, но нужно додумывать.
Сразу было поставлено жёсткое ограничение: разметка не включает в себя оформительские инструменты, а передаёт только смысловые акценты и структуру текста.
И сразу получаем качественные, отполированные многими лбами грабли.
Дело в том, что "смысловых акцентов" много, очень много. Например, вот есть у нас стихотворение, мы его хотим оформить "по-правильному". Значит, у нас должны быть примерно такие "смысловые акценты":
стихотворная строка
строфа (несколько строк, создающих некий ритм)
заголовок, главы, подглавы (если стихотворение большое)
эпиграф (если есть)
подпись (если есть)
А для художественного текста нам понадобятся какие-то средства выделения слов или целых предложений:
полужирный шрифт (анафема!)
курсив (анафема!)
подчеркивание (анафема!)
Но использовать их напрямую нельзя - мы же не художники-оформители, нам надо смысл передать. Значит, начинаются танцы вокруг вопроса "а что хочет сказать автор?". Вот тут он жирный хочет [%%%]нуть - почему? Означает ли жирный, что автор подразумевает более громкое чтение? Или у него тут интонация особая? Или это просто пометка "важное, не забудьте"? А курсив - это что? Цитата? Примечание?
Для всего этого биоразнообразия надо будет придумать свою разметку, а самое главное - обучить авторов ей пользоваться. Чтоб не получилось, что авторы тупо заучили два тега (жирный и курсив) и пользуются только ими.
Именно так.
Достаточно посмотреть, сколько людей стилями в Word-образных редакторах научились пользоваться. А потом вспомним про тут ужас, который может хотеться от нумерации. В духе - иерархический номер для каждого пункта из 4-го списка 6-го абзаца подпункта 12 пункта 6 главы 19 раздела 22 10-го тома.
И да, пункт списка - совсем не одна строчка, а тоже несколько абзацев.
Не всё так сложно как может показаться на первый взгляд. Эпиграф это просто текстовое включение с классом e или epigpaph.
Стихотворения тоже можно вложить во включение с классом poem и тогда срофа будет <stanza> , а сами строчки можно интерпретировать и как <line> или использовать <br>.
[(poem
Cергей Есенин
***
Что это такое?
В этот лес завороженный,
По пушинкам серебра,
Я с винтовкой заряженной
На охоту шел вчера.
По дорожке чистой, гладкой
Я прошел, не наследил…
Кто ж катался здесь украдкой?
Кто здесь падал и ходил?
...
1914 г.
)]Единственно с годом ещё не решил, не везде он в конце указывается, поэтому возможно придётся отдельно размечать
Стихотворения тоже можно вложить во включение с классом poem
Все можно вложить во включение, вопрос не в этом. Сам подход "отказаться от оформления и передавать смыслы" - непрактичен. "Смыслов" получается очень много, а людям, как правило, нужен весьма ограниченный набор оформительских средств.
Как только одно и то же оформление будет получаться в результате разных классов "включений", люди начнут упрощать себе жизнь. Зачем иметь отдельный класс для стихов, если все, что нужно автору текста - чтоб строки не слеплялись вместе?
Смыслов как раз не так и много, гораздо меньше, чем прописывается классов и стилей в сайтостроении. Просто стихи это весьма массовое явление и не грех уделить им внимания. Хотя в данном примере можно использовать и стандартную разметку.
Cергей Есенин
***
Что это такое?
В этот лес завороженный,
По пушинкам серебра,
Я с винтовкой заряженной
На охоту шел вчера.
~~~
По дорожке чистой, гладкой
Я прошел, не наследил…
Кто ж катался здесь украдкой?
Кто здесь падал и ходил?
...
1914 г.Единственный минус несколько большие расстояния между строками при конвертации в html
Единственный минус несколько большие расстояния между строками
Минус тут в том, что вместо разметки используется plain text.
Разметку все-таки не зря придумывают и переизобретают каждые н-цать месяцев. Она как раз для того, чтобы по-быстрому и без запарок разметить текст для дальнейшей обработки.
Но вот когда разметку пытаются сделать панацеей от всех бед - начинаются проблемы. Она очень быстро обрастает огромным количеством расширений и подпорок, что делает ее громоздкой.
...можно вложить во включение с классом ....
А потом начинается стандартный адок с поиском где неправильно поставлена закрывающая скобка, который приводит к тому, что в большом тексте проще пользоваться специализированным редактором, Markdown такой "несовершенный" ровно для того, чтоб можно было писать руками текст и даже через много лет легко его открыть и править.
Мне вообще кажется, что люди, которые в принципе понимают дилемму «семантика vs. оформление» не гоняются за интуитивностью. (А те, кто не понимают, пользуются WYSIWYG :)
С textil сравнивали?
Да, конечно, попадался при первоначальном изучении ландшафта. Как упрощённая альтернатива html вполне себе годная разметка. Единственно смущают такие моменты как +вставленный текст+ - ведь пользователь может плюсы по делу использовать. Хотя и с двойными плюсами тоже нужно обходить сложности, если попадается пару раз С++.
Маркван для общего описания технических и художественных текстов, поэтому он где-то может больше, чем html, а где-то имеет намерено ограниченные возможности.
Для технических текстов надо сразу переходить на (La)TeX. Потому что выразительных возможностей любого языка разметки начнёт нехватать очень быстро.
Не зря LaTeX это по сути стандарт в научной среде, там действительно огромные возможности. Но огромные возможности порождают и сложности набора. Поэтому предпочту простую разметку + вставки-включения TeX формул по необходимости.
Но огромные возможности порождают и сложности набора.
В данном случае это ложное утверждение. Единственная сложность набора, которую я заметил в LaTeX по сравнению с Вашим форматом - необходимость переключать раскладку для ввода элементов языка. Но у Вас тоже есть квадратные скобки, так что...
Поэтому предпочту простую разметку + вставки-включения TeX формул по необходимости.
Каждый чёртов раз, когда я пытался обойтись markdown со вставленными TeX-формулами, мне вскоре приходилось переписать всё на LaTeX.
А может у вас сохранилась та задачка? Я бы хотел на практическом примере попробовать её решить. Можно в личку скинуть.
Целый репозиторий тащить? Не хочу. Она уже давно на много файлов разрослась. В markdown мне не хватает в первую очередь инклуда, для возможности структурировать код разделением на файлы.
я вместо инклуда использую внешнюю систему сборки
то есть например пишем книгу.
src/
part-01/
010.md
020.md
040.md
part-02/
010.md
...И так далее. Ну и дальше find -type f -name '*.md'|sort даёт список, который можно скормить какому-нибудь билдеру html или fb2/epub2. Инклуды изнутри одного маркдауна в другой становятся не так уж и нужны.
Правильно но ли я понял, как в этом примере создать сборник из отдельных рассказов?
Джек Лондон
***
Рассказы
{{
>Белое безмолвие.text
}}
{{
>Подпапка/Zatechktovputi.text (За тех, кто в Пути! Лондон)
}}
Конец сборника
. Хочется долговечного, не зависящего от популярных в настоящее время
программ. Txt, doc, docx, gdoc, rtf, odt и т.д., ну вы поняли.
rtf, не? )
"""
Глава I Неизвестная планета
Вот и зачем в очередной раз что-то новое придумывать про заголовки?
то дефисами подчёркиваем, то тире, затем диезами обозначаем, теперь кавычками впереди.
Такое ощущение, что где-то креативит кто-то и именно это место самое э... проблемное.
Вот терпеть не могу подобные отрицающие комментарии. Такой в маркване дизайн, учитывающий различие заголовков, я его в тексте статьи обосновал.
Могли-бы просто написать, а мне вот такой-то способ кажется удобным, я его применяю. Это было-бы конструктивно.
Когда-то маркдаун позиционировался в замену вики
затем было ещё 2 или 3 маркдаун варианта
в итоге мы заголовки
подчёркивали разными маркерами (-, =, ~, и так далее)
предваряли диезами внутри строки
теперь предлагается предварять на предыдущей строке (sic!) снова разными маркерами
В чём смысл?
Как по мне предварение строки диезами - самый лучший вариант, ибо грепается. Содержание книги (я тоже пишу книги) делается одной командой в консоли:
$ grep '^#' src/part-07/*.md
src/part-07/000.md:# Часть 07. Террор
src/part-07/020.md:## Без радости (гнома)
src/part-07/040.md:## Гориллы
src/part-07/060.md:## Амулет воскрешения
src/part-07/080.md:## Охота на приматов
src/part-07/100.md:## Циклон-Б1А
src/part-07/120.md:## Гарик Сторм
src/part-07/140.md:## Финальные штрихи
src/part-07/160.md:## Специальная военная операция
src/part-07/999.md:## ПерсонажТеперь понятна точка зрения! Спасибо.
Я рассматривал этот вариант, но он мне не понравился с той точки зрения, что замусоривает заголовок и знак # нужен для нумерации (идентификаторы, автонурованные списки и т.п.) В первоначальном варианте марквана заголовки подчёркивались - это красиво, но непрактично, т.к. нужно совпадение с количеством букв, да и ещё моношрифт не везде. В случае надчёркивания эти символы как-бы отделяют часть текста от другой и заголовок воспринимается как единое целое с последующим текстом (проводил эксперименты, так показалось лучше). Что касается разнообразия символов, то, как только их запомнишь (а применив логику это несложно), то без подсчёта количества знаков мозг хорошо воспринимает уровневость. Очевидно, например, что === важнее, чем ----, а ... ещё менее важны. Опять же. если бы вы раньше не сталкивались с привычной вам альтернативой, то и не так сильно резал-бы глаза иной подход.
Что касается разнообразия символов, то, как только их запомнишь (а применив логику это несложно), то без подсчёта количества знаков мозг хорошо воспринимает уровневость.
Есть еще один вариант, который почти никогда не используется - при наборе нужно знать вот все эти сочетания символов. Но они прямо редактором заменяются на что-нибудь подходящее юникодное, что визуально лучше воспринимается.
у маркдауна в целом все хорошо
местами не хватает чего-либо сложного, вроде блоков со стихами или медиа
но если посмотреть на тот же pandoc, то можно выбрать вариант с расширениями и даже сайты верстать на маркдауне
Ага, по типу когда двойной и тройной минус заменяется на тире и длинное тире. Но тут нюанс в том, что такие тексты можно печатать только в специфическом текстовом редакторе. А ещё эти автозамены часто мешают когда нужно ввести именно то, что вводишь.
А ещё эти автозамены часто мешают когда нужно ввести именно то, что вводишь.
как правило, Ctrl-Z (отмена) помогает в 99% гуевых редакторов, ибо автозамена оформляется отдельным действием пользователя
Но тут нюанс в том, что такие тексты можно печатать только в специфическом текстовом редакторе.
Хотеть, чтобы сравнительно сложные тексты (тут вроде о таких речь идет) можно было набирать в настолько простом текстовом редакторе, что там автозамен нет - это, кажется, уже перебор. А если рассматривать именно с точки зрения формата - то, я думаю, можно так сделать, чтобы визуального мусора из сложного сочетания скобок не было. Ну да, будут другие скобки и значки - но, возможно, это глазами проще парсится будет.
Маркван был придуман именно для того, чтобы действительно сложные тексты можно было набрать или поправить даже во встроенном блокноте виндовс. Конечно, если взять тот же vscode и добавить туда маркван-разметку, то печатать было-бы гораздо комфортнее. Эти вспомогательные значки делать сереньким, если скобочку забыл, то подсвечивать. МОжет быть даже фончик добавлять вложенным включениям. Может кто уже делал подобные расширения, подскажите как сделать своё?
Судя по доке у вас # и без того сильно перегружена. То оно id, то оно автонумерованый список, а там глядишь ещё и с URL проблемы всплывут.
Могли-бы просто написать, а мне вот такой-то способ кажется удобным, я его применяю. Это было-бы конструктивно.
Частица "бы" вообще никогда не.
Ваш способ ничем не удобнее практически любого другого способа обозначить заголовки в маркапе. Наоборот - появляются лишние почти пустые строки.
Например, вот способы обозначить заголовки разных уровней в creole markup:
== Крупный заголовок
=== Заголовок поменьше
==== Совсем маленький заголовок аж жуть
Здесь все вполне понятно, есть интуитивно-понятная иерархия, можно будет автоматически сгенерировать содержание документа. Ашоувас?
Не очень понял в чём профит. Сноски аккуратнее? Несколько сомнительная киллер фича. Запоминать символ для уровней заголовков тоже не в плюс.
Что по автооглавлениям и автосносками?
Что про i13n и l10n?
Что насчёт эмбединга одних документов в другие? Заодно вопрос и про поддержку валидаторов оных.
Пока профита не сильно больше чем от какого-нибудь md диалекта. Только mv более многословный получается.
Жаль, что вы не поняли.
Символ заголовка запомнить не так сложно, как кажется на первый взгляд, тем более, что большинство будет использовать только = и -.
По автооглавлениям и автосноскам есть мысли, нужно на практических задачах сначала обкатать. Не всё сразу.
Вставка одних доков в другие есть черновик, см. раздел Маркван-книга, но там ещё кое-то добавить требуется.
Маркван более многословный, потому, что его возможности закрывают потребности создания литературы. А md только для простеньких веб-текстов. Вы сильно удивитесь, если ознакомитесь с правилами оформления пьес и сценариев, тут никакой маркдаун не поможет. Вот попытка подойти к решению задачи по минималистичному отображению сценариев https://markvan.mudrium.ru/markvan-razmetka/spetsifika_publikatsij/razmetka_postanovok.html
звучит как плагин-диалект для md. Но свои велосипеды тоже неплохо. За MathML отдельный респект.
Спасибо. Этот проект больше разминка для мозга, но вдруг будет полезен не только мне. Я пока доволен результатом, начал следующий проект с использованием этого инструмента. Буду развивать по мере появления потребностей.
автору: не обижайтесь, просто оставлю это здесь
а чтоб было конструктивно скажу следующее:
у нового формата обработки текстов крайне важны:
наличие конвертеров в стандартные форматы
наличие парсеров в популярные языки программирования
расширяемость
при наличии этих пунктов возможно (именно, возможно) что появится четвертый
популярность
вот на четвертом уровне, например, конвертер pandoc включит формат в свой состав
попробуйте сами пройти этот квест (сделайте патч на pandoc)
уверен, что в процессе вы найдете в расширениях (уже имеющихся там) маркдаун все, чего самому не хватало
Вот ну так и знал, что кто-нибудь не удержится :)
На самом деле популяризировать это пока рано, нужно сначала чтобы стандарт принял более чёткие очертания, проверенные на ряде проектов. Мне бы ментора по программированию, доработать html конвертер, чтобы не стыдно было его выложить на Гитхаб.
Про pandoc интересно, они там к единому формату всё приводят и потом переконвертируют во что угодно или пишется 1к1 для каждого соответствия?
https://pandoc.org/using-the-pandoc-api.html#pandocs-architecture
Pandoc is structured as a set of readers, which translate various input formats into an abstract syntax tree (the Pandoc AST) representing a structured document, and a set of writers, which render this AST into various output formats. Pictorially:
[input format] ==reader==> [Pandoc AST] ==writer==> [output format]
This architecture allows pandoc to perform M × N conversions with M readers and N writers.
На самом деле популяризировать это пока рано
в статью зачем писали? именно для этого
Вот пример простой маркван-разметки:
В этом примере, "Мой первый рассказ" – это не заголовок первого уровня, а название документа. Оно одно для всего документа, и логичнее его отнести к метаданным, а не помещать в контент. Если бы я писал этот же текст на маркдауне (с прицелом потом его во что-то печатное конвертировать pandoc'ом), то я бы сделал как-то так:
---
title: Мой первый рассказ
---
Глава I. Неизвестная планета
============================
Удачная находка
---------------
Прежде, чем начать своё повествование, расскажу вам весьма интересную, но **жуткую**
историю про переселенцев в Калахари.
Или так:
---
title: Мой первый рассказ
---
# Глава I. Неизвестная планета
## Удачная находка
Прежде, чем начать своё повествование, расскажу вам весьма интересную, но **жуткую**
историю про переселенцев в Калахари.
Кстати, почему вы хотите "надчеркивать" заголовки, а не подчеркивать? Синтаксис с подчеркиванием заголовков символами = и - (setext-style headers) есть еще в самой первой спецификации маркдауна от Грубера (наряду с более привычными atx-style headers): https://daringfireball.net/projects/markdown/syntax#header
Благодарю за конструктивный комментарий.
Следует учитывать, что в голове у обычного человека нет понятия метаданные, поэтому стремился указывать сущности как они есть. При разработке своей спецификации, я намерено не ориентировался на привычки продвинутой аудитории, но подсматривал удачные решения. В своё оправдание могу сказать, что в маркване, текстовые заголовки соответствуют markdown = и -, только помимо них есть Части, Главы и само Название.
Про надчёркивание, чтобы не дублировать оставлю ссылку на ранее оставленный комментарий https://habr.com/ru/articles/791128/comments/#comment_26477972
Сноски и ссылки
Есть же более-менее привычный синтаксис для сносок, почему бы его не позаимствовать?
Here's a simple footnote,[^1] and here's a longer one.[^bignote]
[^1]: This is the first footnote.
[^bignote]: Here's one with multiple paragraphs and code.
Indent paragraphs to include them in the footnote.
`{ my code }`
Add as many paragraphs as you like.
Да, видел. Здесь заложен образный смысл надстрочности указателя сноски. Но я захотел сократить, ведь если цифра, то [^2], а, если звёздочки, то лишний символ [^**]. В маркване [*2] и [**], соответственно. И плюс отсылка к самой теме сносок, т.к. они преимущественно звездочковые, когда их мало.
Ещё важна лаконичность содержимого сноски:
|* Это текст сноски.Мне кажется так эстетичнее.
А это текст со ~[ссылкой]~, адрес которой должен находиться в следующей строке.
|~ example.com (Пример гиперссылки)
Чем это лучше стандартного способа ниже?
А это текст со [ссылкой][1], адрес которой может находиться на любой строке документа.
[1]: example.com (Пример гиперссылки)
По сути ничем, только чуть красивее и глаз не цепляется за цифру и мозг не пытается подсознательно её расшифровать - меньше когнитивная нагрузка.
ИМХО, наоборот. Цифра в скобочках выглядит аккуратнее, чем тильды. Сопоставление цифры - меньшая когнитивная нагрузка, чем восприятие спецсимволов.
Не соглашусь в этом, но пропустим. Тогда другой аргумент: 4 символа против двух в строке со ссылкой!
А если посмотреть не на отдельные детали, то ~[...]~ кореллирует с обозначением строчных включений, например =[...]= или &[...]&
Кстати, была и такая идея и с цифрой после тильды
А это текст со [ссылкой][~], адрес которой должен находиться в следующей строке.
|~ example.com (Пример гиперссылки)но пока на текущем варианте остановился, хотя может всё и поменяться
Вот, теперь мучаюсь, может переделать так?
Вот первая ссылка[~] и ссылка из [двух слов][~]так большая аналогия со сноской
Как вы будете делать две ссылки в одной строке?
Здесь всё просто, они должны идти по порядку, однако, если перейти на синтаксис из https://habr.com/ru/articles/791128/comments/#comment_26480266 то можно и циферки использовать
Про "включения" не особо уловил идею, но похоже вы заново изобретаете admonitions
Ну это вы перегнули. То, что использовал сокращение для именования класса - так это логичное совпадение. А включения понять несложно. Вот есть некое повествование состоящее из слов, а когда нужно в повествование вставить что-то отличающееся от потока, будь то картинка, или кусок кода или просто справка - это включения.
Я бы посоветовал взять готовый парсер маркдауна с максимальным набором нужных для своих задач фич (из коробки, или в уже готовых расширениях). Недостающие фичи реализовать в своих расширениях.
А писать вообще всё с нуля... Ну не знаю...
Я делился опытом использования markdown для художественной литературы в статье https://habr.com/ru/articles/720584/, там без самописных расширений обошлось.
А, читал, вашу статью, когда она вышла!!! Тоже помогла.
По поводу написания конвертера в html. Готовый взять не получится, т.к. логика местами совсем разная. Я пытался что-то посмотреть, но там столько строчек кода...
На самом деле просто написать, чтобы работало и проверить свою гипотезу было не так сложно. Хотелось-бы сделать код более эффективный алгоритмически, понятный для внешнего читателя и учитывающий разные случаи ошибок пользовательского ввода.
По поводу написания конвертера в html. Готовый взять не получится, т.к. логика местами совсем разная. Я пытался что-то посмотреть, но там столько строчек кода...
Не надо переписывать чужой код, надо найти расширяемую библиотеку на своем любимом языке программирования, и написать немножко своего кода для расширения. Все стандартные фичи маркдауна будут обрабатываться готовым, надежным и протестированным кодом из библиотеки. Для нестандартных но полезных найдется множество сторонних расширений. И только что-то свое, уникальное и инновационное придется закодировать самому.
Например, вы пишете на Python. Берете Python-Markdown. Изучаете его Extension API. Пишете и публикуете экстеншн для всего того что вам не хватает.
И все в выигрыше. Вы экономите время, написав совсем немножко кода, а не полноценный парсер с нуля. Комьюнити в выигрыше – можно подключить в свой проект новую фичу парой строчек в конфиге, и не надо изучать 15-й стандарт. Читатели, ждущие вашего контента тоже в выигрыше – они читают вашу новую поэму/пьесу/статью, а не ждут пока автор допилит новый парсер для ее публикации.
Сразу было поставлено жёсткое ограничение: разметка не включает в себя оформительские инструменты, а передаёт только смысловые акценты и структуру текста.
А вот это категорически приветствую :-)
Концепция включений в markvan-разметке текстов