В Нью-Йорке сотни парков, что не удивительно для такого огромного города. Удивляет, что их полно даже на полностью застроенном Манхэттене. И это я не говорю про Central Park, который просто невозможно пропустить. У меня было некоторое количество времени на то, чтобы походить по некоторым из них. Начнём, пожалуй, с самого большого и известного.

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

Продолжим похождения по нью-йоркским и манхэттенским достопримечательностям и просто окрестностям.

Нью-Йорк — это моя первая вылазка в другую часть света. Один из самых больших городов мира и самый большой город США. Практически всё моё пребывание прошло в пределах Манхэттена, поэтому показывать я буду его, хотя уверен, что и в других районах Нью-Йорка тоже много чего интересного.

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

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

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

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

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

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

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

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

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

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

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