Языки разметки

Давайте поговорим о языках представления структурированного текста. То есть то что вполне можно комфортно читать в обыкновенном plain виде, а главное натравить на это какой-нибудь git и комфортно читать всё в git diff.

Это действительно тебя беспокоит? Давай.

При этом всё это должно быть для специфических задачь, а значит элементы разметки стандарты => сносная предсказуемость при конвертации во что-нибудь более презентабельное типа pdf. В последнем опционально прикручивание всяких стилей с высокой гибкостью, как css для html.

Ага.

ИМХО контент в xml для редактирования руками не очень подходит, хотя наверно у него немало сторонников.

Конечно.

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

Ну да.

Че сказать то хотел?

Ну, языки разметки — это хорошо.

Latex — это тоже хорошо.

AsciiDoc — тоже хорошо, хоть и органиченно...

tex

легко парсить

Упорот? TeX Тьюринг-полон. Это язык программирования, а не разметки текста. И вообще,

You actually have to debug LaTeX documents, and I bet that the best TeX debugger is somewhat worse than the worst C debugger out there.

© http://www.yosefk.com/blog/fun-at-the-turing-tar-pit.html

Я за markdown для простых случаев и отсутствие искусственных стандартов для сложных (т.к. всё равно в стандарт всё не впихнуть, доказано odt и разницей в одинаково соответствующих ISO того времени мелкософтофисе и опенофисах). Алсо, *TeX сильно привязаны к тому, что выхлоп будет на бумаге (либо pdf из листов в A4/A5/прочем_формате_нарезки_мёртвых_деревьев), что для электронных документов не айс. И вики тоже вполне себе ок.

контент в xml для редактирования руками не очень подходит

поэтому руками его и не редактируют, следовательно, основанный на xml формат — для сложных случаев.

И да, xml — язык разметки ДАННЫХ, не текста. Формат разметки непосредственно текста — поверх xml.

поэтому руками его и не редактируют

Ну почему же, фанаты DocBook, в т.ч., ЕМНИП, Эрик Реймонд, именно руками его и редактировали.

Ну почему же, фанаты DocBook, в т.ч., ЕМНИП, Эрик Реймонд, именно руками его и редактировали.

Давай теперь не мыться, чо, как предки завещали.

Такой вот простенький markdown в обработке через pandoc и xelatex дает такую вот красивую PDF-ку. Удобно и классно!

Давайте поговорим о языках представления структурированного текста.

Приезжай, поговорим

всё это должно быть для специфических задачь
задачь

специфических чего?

сносная предсказуемость при конвертации во что-нибудь более презентабельное типа pdf

это к LaTeX

latex ... ассоциируется со сложной системой вёрстки...

Не такая уж и сложная

(а добиться этого нелегко)

Ну, для домохозяек и HTML неимоверно тяжёл. LaTeX же предназначен в первую очередь для людей с научно-техническим образованием (математики, физики, программисты и т.д.), так что широкого применения он навряд ли получит, хотя жаль.

то ли я его не осилил и не хочу осиливать то ли система не очень гибка в переработке текстовой разметки

Тут ситуация несколько неоднозначная. С одной стороны, некоторые вещи делать проще, чем в том же LibreOffice, но кое-где либра обконяет латех. Каждому своё.

просто она заточена на свою нишу (ну есть там tex4ht)

да, а есть ещё texi2html, texi2pdf и т.д.

Одобряю, годно.

а что здесь обсуждать-то? Обсуждение начнется после первого же предложения чего-либо лучше markdown.

могут конечно выступить сторонники rst, но markdown с расширениями, такими как, например, kramdown - в любом случае уделывает все существующее на данный момент, а именно по простоте освоения, использования и применения.

Чем rst хуже в контексте простоты освоения, использования и применения?

Ничем.

markdown — слишком уж примитивная штука. Годится лишь для совершенно попсовых вещей. Формулы ты туда как воткнешь? А перекрестные ссылки? А сложные таблицы? А еще уйму всякой хрени?

ТС не упоминал о формулах, т.к. в таком случае ответ был бы очевидным.

Формулы ты туда как воткнешь?

Не нужно.

А перекрестные ссылки?

См. выше.

А сложные таблицы?

Сверстаю в Inkscape/Dia и вставлю картиночкой.

Markdown нормуль.

Ты упорот.

Кстати, типикал случай. ЗАЧЕМ нужны формулы/перекрёстные ссылки/сложные таблицы в git diff'абельном околоплоском тексте? Чтобы доказать, что это возможно в теории — ок, но осознанно пользоваться этим для работы — занятие вроде кодинга на брейнфаке или написания тетриса на sed'е. Ну или написания инита на баше.

Я вообще не понимаю, нафига может появиться желание делать diff для обычных текстов.

Документы? HTML + CSS, TeX. Если ты упорот, XML.

В реальной жизни вообще формулы сложнее чем 2+2 нужны только школоте и студентоте.

Не только, проблема лишь в том, что формулы разным категориям людей нужны разные. Собственно, если нет ничего готового — можно либо расширять LaTeX (занятие для сильных духом, также см. brainfuck), либо произвольную реализацию того же markdown (заметно проще). Конечно, есть тонна готовых LaTeX-пакетов, обеспечивающих надёжный вендор лок-ин и есть приветливое красноглазое сообщество, но это не означает прямоту решения.

Каким образом тьюринг-полнота влияет на сложность парсинга?

Ты так говоришь, будто ТеХ — это что-то страшное... Ничего страшного в нем нет, если им пользоваться часто. А если редко — то и из вима можно забыть, как выходить...

Чтобы узнать, что получится из TeX-документа, его надо запустить (в том же смысле, что и скрипты). Без этого даже хороших предположений сделать не получится. Парсинг без собственно запуска мало что даст.

Ты так говоришь, будто собирать корабли в бутылке — это что-то страшное...

Вообще — я оцениваю понт, но есть же более простые пути. TeX действительно не так страшен, как, например, шаблоны C++ (см. boost).

В Racket есть секретный язык разметки Scribble. По синтаксису слегка похоже на латех, только вместо бэкслеша у него @.

#lang scribble/base
 
@title{Котики}
 
@abstract{Один кот поспал на микроволновке, и всё у него стало хорошо.}
 
@section{Микроволновка}
А тут тёпленько! Уложусь-ка я сюда. @italic{Мрр-мррр-мррррр...}

Главный кайф в том, что оно разворачивается не в наркоманский макроязык из 70-х, а в S-выражения. @ - это просто синтаксическое расширение, на самом деле весь файл - исходник на Racket, можно писать человеческие макросы, подключать библиотечные модули и т. д. Из коробки оно транслируется в LaTeX и HTML.

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

Парсинг не имеет никакого отношения к запуску.

Ты не можешь определить, что означает синтаксическая единица, не запустив TeX-скрипт (документом его назвать нельзя). Следовательно, не можешь его распарсить.

Чоооо?

Задача парсинга - выделить «синтаксическую единицу», а не определять что она означает. Учите матчасть.

Да, примитивна. Но не в этом ли ее плюс?
Любой технический переводчик сможет перевести или поправить текст в Markdown, запустить скрипт и получить PDF'ку, не углубляясь в магию TeX/LaTeX.
Кстати, именно таким образом и была переведена книга Скотта Чакона - Pro Git. Суровые TeX/LaTeX'овики наваяли няшный шаблон, написали скрипты, а текстовую массу и кодовые вставки вынесли в простенький markdown и дали на растерзание переводчиками.
Итог - книга в кратчайшие сроки полностью переведена на 10 языков (+ ещё неполные переводы на 21 язык).
А для сложных научно-технических статей TeX/LaTeX - стандарт, безусловно.

Выделить синтаксическую единицу — это задача токенизера, не парсера. Учите матчасть.

Лексическую - токенайзер, синтаксическую - парсер.
P.S. Или у вас какая-то своя, особенная матчасть?

Я за бан.

Конкретный пример: как твой гипотетический парсер будет обращаться с \def?

Точно так же как и компиляторы си обращаются с

#define

latex
С другой стороны его легко парсить

Сразу видно — компентентный специалист. Может поможешь мне хотя бы html распарсить awk'ом? А то я всю голову себе сломал, а для тебя это не составит труда!

Тебе обязательно html awk'ом парсить?

Да. Обязательно. Html. Awk'ком. С многострочными тегами...

Вот же людям делать нечего! Ты еще на чистом баше накатай скрипт для распознавания речи =D

Точно так же как и компиляторы си обращаются с

#define

Удачи.

http://tex.stackexchange.com/a/4205/52102

То есть вся аргументация свелась к цитированию некоторого источника, который ты даже не осилил понять?

То есть ты не можешь построить синтаксическое дерево из TeX-исходника, не запуская его. Максимум — токенизировать.

И да, прочитай слово «runtime» по ссылке и скажи ещё раз про #define.

А я причем? Я-то понимаю весь маразм задачи и знаю что есть, хотя бы sed, но ....

Спасибо за ссылку. Познавательно. Только я так и не понял, о чем вы спорите. На кой черт парсить теховский код чем-то, не являющимся головой программиста или самим компилятором теха?

ты не можешь построить синтаксическое дерево

Не путайте построение синтаксического дерева и его валидацию.

Примитивно: допустим, я поверил топикстартеру, что расширять *TeX — легко. Мне понадобилось дебажить что-то из моих расширений. Мои инструменты кроме компилятора теха и Метода Пристального Взгляда?

Мне понадобилось дебажить что-то из моих расширений.

Методика совершенно аналогична методике дебага сишных программ: printf (а в латехе это — либо диагностические выхлопы в stdout, либо запись в какой-нибудь файл, а еще и tracingmacros).

Но таки даже tracingmacros не поможет при всяких сложных вещах с кучей \noexpand, \expandafter, \let и сменой \catcode.