Комментарии 29
Судя по npm, remarkable пару лет не обновлялся и в 5 раз менее популярен, чем markdown-it
а почему не Pandoc?
решил остановиться на pure-JavaScript решениях для большей гибкости
Не знал о таком (точнее слышал, но никогда не пользовался). Сейчас скачал себе на десктоп pandoc и прогнал через него тестовый файл вот такой командой
pandoc -f markdown -t html text_for_testing.md -o t.html
Я не знаю, насколько можно кастомизировать поведение pandoc-а, но из коробки он выдал такие ошибки:
перевод строки в текстовых блоках
вложенная цитата
лист в цитате
выделение цветом (==)
В целом неплохо (даже подсветку синтаксиса осилил - выделил переменные и т. п. css классами), но все же не идеальный результат
Есть ещё нативные варианты, например, https://github.com/rsms/markdown-wasm
Если речь идёт о скорости, то почему их не рассматривать...
Спасибо, не знал о таком! Попробовал.
Вот его live demo - https://rsms.me/markdown-wasm/
Тестировал на том же тестовом файле, что и все остальные парсеры
Что не работает:
перевод строки в текстовых блоках
выделение текста
нижнее подчеркивание (тег <u>) - кажется, он просто весь html игнорирует
выделение цветом (==)
подстрочный шрифт (распознается как зачеркивание)
надстрочный шрифт
html игнорируется, так что ни картинка, вставленная тегом <img>, ни <iframe> не рендерятся
Cудя по readme проекта, html можно включить в настройках. Но почему настройки нельзя покрутить в live demo - это хороший вопрос...
для меня самое главное
1) через cntrl +v подхватывалась картинка
2) скопированный стиль из сайта при вставки сохранял стилистику
ни один из вашего топ 3 это не умеет делать - печаль
Asciidoc не пробовали? Из коробки и в html, и в pdf.
Спасибо за предложение! Попробовал)
Нашел вот такое демо https://asciidoclive.com/edit/scratch/1
Вставил тестовый текст (есть в публикации выше)
Результат не очень впечатляющий. Помимо стандартных проблем с переводом строки в текстовых блоках и вложенных цитат, есть ряд совсем "детских" проблем. На мой взгляд, этоn проект справляется даже хуже, чем антигерой данной статьи - MarkdownDeep...
https://github.com/jichu4n/asciidoclive не обновлялся с 2016. Референсный процессор живет на https://github.com/asciidoctor/asciidoctor Есть плагин для IDE от авторов https://plugins.jetbrains.com/plugin/7391-asciidoc
Не, я не спорю - больше редакторов хороших и разных. Давний поклонник markdown, но влез в asciidoc и прилип. Для паблишинга показался гибче MD и значительно проще TEX. Проблем пока не поймал, пользуюсь плагином. Бросьте в личку кейс, пожалуйста, мейнтейнеры отвечали в течение нескольких часов.
Обновил PyCharm, установил последнюю версию AsciiDoc. Запустил превьюшку. На первый взгляд ошибки те же, что и в https://asciidoclive.com/edit/scratch/1 :(
А MarkedText?
Asciidoc, к сожалению, не так лаконичен, прост и читабелен как Markdown. Например, об этом сказано даже в спеке CommonMark
del, не дочитал пост до конца
Есть нативное готовое решение: https://content.nuxtjs.org/
Если коротко - это смесь из статически генерируемых страниц из {md, json, yml, etc} файлов в html и все это приправлено vue и nuxtjs. В последней версии даже появились markdown-компоненты
Сам недавно заинтересовался про nuxtjs, планирую как-нибудь мигрироваться на него, когда руки дойдут... Классно, что там есть такая библиотека!
Я нашел ссылку на демку content-а на их странице на github https://stackblitz.com/github/nuxt/content/tree/main/examples/essentials/hello-world?file=app.vue
Попробовал прогнать через нее тестовый Markdown
Что не работает:
перевод строки в текстовых блоках
выделение текста
выделение цветом
подстрочный регистр
надстрочный регистр
В целом проблемы не критичные и с ними можно жить :)
но я решил остановиться на pure-JavaScript решениях для большей гибкости
Не надо вуалировать истину, которая состоит в том, что выбор был сделан с целью исключитть затраты на изучение других языков, ну а JS видимо уже был изучен, значит в его случае затраты минимальны.
Но в тексте я не увидел подробностей, которые можно было бы указать, если бы автор реально изучал исходный код парсеров. Только ссылки на документацию и её неполноту. При таком подходет выбор парсеров на JS ничем не оправдан кроме личного пристрастия автора.
Ну и нет стандартного для подорбного обзора сводного материала. Обычно это простейшая таблица, в которой рядом со столбцом с названиями парсеров были бы столбцы с их характеристиками. Вместо полезной для сравнения таблицы имеем пару субъективных "выводов" про скорость (кстати, почему-то здесь таблицу получилось сделать), и про плагины. Но даже эти выводы разбросаны по статье, а в итоговом "заключении" о них вообще ни слова, хотя о том, что автор собой доволен, в заключении слова есть.
Ну и немного о цели автора. Он заявляет, что хочет сделать сайт. Ну ладно, но почему на маркдауне? Просто потому, что ничего другого не знаем? HTML, вообще-то, очень простая штука, сильно проще JS. Видимо опять рулят привычки и нежелание изучать новое. В итоге - субъектив на субъективе. Плюс личные впечатления и самореклама.
Ну а почему нет? Автор выбирал парсер для себя. Почему он не должен руководствоваться привычками? Что плохого в минимизации затрат и усилий? И статья называется не "какой парсер лучше выбрать", чтобы претендовать на объективность.
Если я знаю Java и захочу сделать сайт, то в первую очередь буду искать движки на Java (кстати, я так делал и нашел SparkJava)
Такой подход позволяет первоначально сильно сузить широту выбора. Иначе чем больше выбор - тем дольше выбирать.
А поделитесь пожалуйста своим набором тестовых md-файликов, которые вы прогоняете на различных парсерах.
Не хотите добавить в сравнение $mol_text?
Лицензия MIT, демо, дока, бенчмарк, отзывчивый всё ещё живой мейнтейнер.
Что не работает:
Перевод строки разрывает абзацы.
Нумерованные списки. Не сложно добавить в принципе.
Экранирование в блоках кода - просто используется отступ.
Подчёркивание, раскрашивание, суперскрипт, субскрипт. Не сложно добавить в принципе.
Экранирование - используется инлайн код.
Линия разреза. Не сложно добавить в принципе.
Сырой HTML. Видео и приложения вставляются так же как и картинки.
Приятные бонусы:
Фавиконки у ссылок.
Проверка ссылок на безопасность.
Виртуальный или ленивый рендеринг.
Быстрое копирование кода.
Номера строк в коде.
Подсветка найденного.
Логика работы простая: одним парсером разбивается на блоки, потом попадающие в видимую область блоки парсятся уже вторым парсером и рендерятся. Можно настроить любой аспект, конечно, но лучше просто прислать пул реквест.
А вы на hugo не смотрели? Тоже можно из md делать сайты
Спасибо, посмотрел.
Hugo - это генератор статических сайтов, а я предпочитаю писать single page applications, так что это не то, что мне нужно. Он использует парсер goldmark, написанный на go, то есть он не работает в браузере.
Демки не нашел, но зато есть обзорная статья на markdownguide - https://www.markdownguide.org/tools/hugo/
Там нет проверки вложенных цитат, но в остальном hugo вроде поддерживает все, что нужно за исключением:
подсветки синтаксиса
подстрочного регистра
надстрочного регистра
Кстати, есть ещё неплохой https://mdxjs.com/
Уже со всеми готовыми пакетами для полноценного парсинга markdown
Как я Markdown парсер выбирал