Как работают перекрестные ссылки в spec.txt для GFM? - PullRequest
0 голосов
/ 05 ноября 2019

Prelude

В спецификации GFM сказано, что:

Этот документ создан из текстового файла spec.txt, написанного наУценка с небольшим расширением для параллельных тестов. Сценарий tools/makespec.py можно использовать для преобразования spec.txt в HTML или CommonMark (который затем можно преобразовать в другие форматы).

Мне не удалось найти общедоступный репозиторий, содержащий эти файлы, ноspec.txt можно найти в том же веб-каталоге, что и сама спецификация. Это не мой главный вопрос, но я был бы рад, если бы кто-то мог указать на хранилище, в котором эти файлы официально хранятся.

Основное предположение

Согласно приведенной выше цитате, я предполагаю, что всекод в spec.txt, кроме кода, предназначенного для параллельных тестов, является допустимым GFM .

Основной вопрос

Вspec.txt, есть следующий код:

## Characters and lines

Any sequence of [characters] is a valid CommonMark
document.

A [character](@) is a Unicode code point.  Although some
code points (for example, combining accents) do not correspond to
characters in an intuitive sense, all code points count as characters
for purposes of this spec.

В предоставленной спецификации , ссылка [characters], а также ссылка [character](@) былипреобразуется в эту перекрестную ссылку:

https://github.github.com/gfm/#character

Реализует ли этот синтаксис перекрестные ссылки (называемые якорями) в GFM? Существует популярный вопрос о такой функции , который предполагает, что не существует чистого решения Markdown для перекрестных ссылок - однако, если этот синтаксис, основанный на (@), реализован в синтаксическом анализаторе, который анализировал spec.txt, почемуэто не указано в спецификации?

1 Ответ

1 голос
/ 06 ноября 2019

Официальный репозиторий для спецификации Commonmark можно найти по адресу commonmark / commonmark-spec (копии спецификации в других репозиториях скопированы отсюда). Мы видим, что файл spec.txt в этом репо также содержит с тем же синтаксисом. Следовательно, это относится не только к GFM, но и к Commonmark в целом (из которых GFM является расширением).

Как объяснено в commonmark / commonmark-spec # 578 (и, возможно, в других местах) в отношении файла spec.txt:

Примечание: это НЕ отдельный файл общей метки. Он находится в специальном формате, который предназначен для обработки с использованием tools/make_spec.lua.

Фактически, если мы посмотрим на tools / make_spec.lua в репо, мы увидимчто это скрипт-обертка, который предварительно обрабатывает файл spec.txt перед выводом спецификации в одном из нескольких поддерживаемых форматов. Обратите внимание, что одним из этих форматов вывода является Commonmark. Если вы запустите сценарий с commonmark в качестве выходного формата, вы получите документ Commonmark с обычными ссылками Commonmark вместо специального синтаксиса. Фактически, если вы передадите файл spec.txt непосредственно в Commonmark (без предварительной обработки в tools/make_spec.lua), вы не получите в ответ документ с правильно отформатированными ссылками. Таким образом, мы можем сделать вывод, что речь идет не о Commonmark, а о каком-то пользовательском дополнении, которое используется только для разработки спецификации. Это объясняет, почему он не указан в спецификации.

К сожалению, я не могу найти документацию о том, как работает синтаксис где-либо. Readme для спецификации кратко упоминает специальный синтаксис кодового блока, используемый в спецификации, но не затрагивает внутренние ссылки.

...