Редакция [dikmax’s blog] приветствует тебя, %username%!

Самое интересное: Карта путешествий, Планировщик маршрутов, ООП в JavaScript, Путешествие по Европе 2013, Осло, Рига, Вильнюс, Весенние каникулы, Путешествие по Европе 2014.

Парсер для CommonMark

Markdown logo

Все началось с того, что мне понадобился парсер для Markdown, который строит AST, а не пытается сразу выдавать готовый HTML. А ещё было желательно, чтобы парсер был написан на Dart, так как проект я собирался писать именно на этом языке. Но, к сожалению, обнаружился только один парсер для Markdown, написанный на Dart. Поэтому идею пришлось отложить до лучших времён и сесть за написание своего велосипеда парсера.

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

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

Библиотека md_proc на GitHub, pub.dartlang.

В самых ближайших планах реализовать восстановление Markdown обратно из AST, а также поддержка самых распространённых и нужных расширений, вроде TexMath, Footnotes, Smart punctuation и других. Ну и, конечно, поддержка совместимости с CommonMark тоже обязательно будет, тем более, что CommonMark ещё должен немного поменяться до того, как будет опубликована официальная версия 1.0. И уже после этого можно будет вернуться к первоначальному проекту.

CommonMark

Markdown logo

Пару недель назад в блоге Coding Horror появилась запись о том, что объединённые усилия GitHub, StackOverflow и ещё нескольких компаний увенчались успехом и они готовы представить общественности точную спецификацию стандарта Markdown.

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

Когда создатели только объявили об окончании основных работ над спецификацией, её назвали Standard Markdown. И тут же поднялось множество криков, что они пытаются украсть авторство Markdown у Джона Грубера. Ведь действительно, кто будет смотреть на просто Markdown, когда есть Standard Markdown. Но позиция самого Грубера тоже не очень понятна. За 10 лет существования формата он не предпринял ничего, чтобы исправить все те проблемы и неясности, что существуют в Markdown. По мнению Джона, именно эта неточность формулировок и сыграла главную роль в популярности этого формата. Но теперь, когда другие проделали эту работу, он высказал свое «фи». Что же, автор есть автор. И после некоторого обсуждения проект переименовали в CommonMark.

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

Проблемы начинаются, когда пишешь парсер для этого формата. Из‑за отсутствия чёткой спецификации каждый начинает изгаляться как может. Один и тот же текст может подразумевать несколько различных вариантов разбора, и нужно быть очень осторожным, если, например, хочешь добавить блок с кодом куда‑нибудь в список. Спецификация CommonMark предлагает наиболее логичные варианты чтения текста, но не самые простые. Поэтому, чтобы написать парсер, соответствующий данной спецификации, придётся изрядно постараться.

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

Dart и highlight.js

highlight.js: Syntax highlighting for the Web

Когда я создавал этот блог, нужно было что‑то делать с подсветкой синтаксиса для примеров кода, которые здесь появляются. После рассмотрения различных альтернатив (уже и не помню, каких именно) я остановился на highlight.js. На тот момент эта библиотека поддерживала все необходимые мне языки. А потом я решил поэкспериментировать с
Dart… Ну и написать пару постов о нём. Смотрю, а поддержки Dart в highlight.js нет. На сайте проекта сказано, что разработчики не выполняют заказы на добавление новых языков, если хотите поддержку нового языка, то реализуйте её сами.

Что делать, реализовал поддержку и отправил pull request на добавление языка в библиотеку. А пока использовал свою сборку из своего репозитория. Прошло полгода — и теперь мой патч наконец включили в библиотеку! Более того, новая версия 8.2 уже вышла и вы можете ей воспользоваться, чтобы добавить поддержку подсветки исходного кода на Dart (и других языках) к себе на сайт.

Озёрный край

Что‑то я вам всё про заморские красоты рассказываю, а про родные, белорусские, ни слова. Надо бы это исправить.

Читать дальше...

Как сделать свою карту

Сегодня я расскажу вам, как с помощью JavaScript и d3 нарисовать карту, подобную моей.

Читать дальше...