search

colorer / Colorer-schemes

Syntax and color schemes for colorer library
30 stars 26 forks source link

Markdown: раскраска и html-тэги #155

Open johnd0e opened 1 month ago

johnd0e commented 1 month ago

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

Пример:

- **bold**, _italic_

Исходный код:

- **bold**, _italic_

<details>

- **bold**, _italic_

</details>

В настоящий момент markdown.hrc не учитывает этого, и не красит содержимое между \<details>, и очевидно многими другими тэгами.

Не исключено что между диалектами маркдаун тут вохможно некоторое отличие, но по крайней мере gfm есть чёткая спецификация. См. пункт 6: https://github.github.com/gfm/#html-block

@nightroman

nightroman commented 1 month ago

Естественно, думал об этом. Как видите, решение - не поддерживать хтмл. Вряд ли я его поменяю, сразу говорю, чтобы не было ложных ожиданий. Все против этого. Не особо надо (спорить бесполезно, кому как, конечно). Плюс диалекты и наличие пустых строк после чего-то в качестве критерия закрывания блока (колорер не работает с 2+ строковыми конструкциями).

NB Если бы это был мой репозиторий, я бы тикет закрыл.

johnd0e commented 1 month ago

решение - не поддерживать хтмл. Вряд ли я его поменяю

Это ничего, значит просто обменяемся мнениями)

...и наличие пустых строк после чего-то в качестве критерия закрывания блока

Этот критерий можно ослабить, исходя из двух следующих соображений:

  1. Для завершающего тэга пустая строка не всегда обязательное требование, может быть также:

    ...or the last line of the document, or the last line of the container block containing the current HTML block

  2. Перед колорером вовсе необязательно ставить задачу строгого контроля чем там завершается тэг. Сейчас этого не делается, содержимое просто не красится. Я предлагаю в этой же ситуации содержимое красить. Для обоих случаев (и сейчас, и если моё предложение будет принято) будут граничные случаи, в которых тэги будут восприниматься иначе чем в спецификации, но беды в этом нет, потому что a) Полностью корректный код будет в итоге раскрашен верно по крайней мере в 99% случаев b) Не полностью корректный код будет тоже раскрашен колорером, и отражать намерение пользователя. То что рендерится он может иначе - это не проблема колорера.

TL;DR:

nightroman commented 1 month ago

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

johnd0e commented 1 month ago

Попробуйте, покажите, что получилось.

Э.. Кхм.. Для меня hrc что китайская грамота, поэтому сложновато выходит попробовать.

nightroman commented 1 month ago

Тоже в этом не как рыба в воде. И работа над схемами идет с перерывами, все забывается. И маркдаун не самая простая схема.

johnd0e commented 1 month ago

Спасибо вам за неё!

nightroman commented 1 month ago

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

Но надо эти теги как-то особым способом пометить, чтобы другие "нормальные" случаи их применения не изменить. В идеале (ибо наибольшая гарантия), оговоренным хтмл комментом на той же строке. Или только необычный формат распознавать, типа DETAILS, и только так. Тогда более традиционные details будут считаться обычными, как сейчас.

Что думаете? Лучше, чем ничего. Другие практичные предложения? (Сделать все "по-честному" - непрактичное, задача не имеет решения в общем случае)

johnd0e commented 1 month ago

...теги типа 6 как самостоятельные и полные, а не блочные конструкции

Но так ведь мы потеряем возможность подсветки парного тега. Или нет?

чтобы другие "нормальные" случаи их применения не изменить.

Какие другие случаи имеются ввиду? Я честно говоря даже не вижу пока что за "обычные" \<details> могут вдруг оказаться в markdown, и как их предполагается иначе обрабатывать.

nightroman commented 1 month ago

Но так ведь мы потеряем возможность подсветки парного тега. Или нет?

Потеряем, да.

Какие другие случаи имеются ввиду?

Когда внутри хтмл, а не маркдаун. GFM хорош, но не единственный диалект. И даже в нем, смотрите примеры по ссылке, внутри тегов то маркдаун, то хтмл.

johnd0e commented 1 month ago

Я наивно полагал что в схеме можно просто перечислить теги из пункта 6, и с их содержимым всё будет однозначно.

nightroman commented 1 month ago

Не совсем понимаю, что имеется в виду, поэтому нечего ответить :)

johnd0e commented 1 month ago

Сейчас же html-теги "ловятся" каким-то регэкспом.

Не заглядывая в детали устройства схемы рискну предположить, что можно "забить" в этот регэксп конкретный перечень строк (соответствующий перечислению из пункта 6), и получившиеся блоки парсить как маркдаун.

Насчёт других диалектов.

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

nightroman commented 1 month ago

(1) Да, несколько упрощенное понимание. Колорер не так прост. И атрибуты тегов это не маркдаун. (2) Не буду спорить. Но делать буду, как думаю "правильнее".

P.S. Попробованы уже разные подходы, не думайте, что фокус на одном.

johnd0e commented 1 month ago

Не понял о каких атрибутах речь, мы вроде бы их выше никак не затрагивали.

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

nightroman commented 1 month ago

Обычные атрибуты на хтмл тегах. Класс и вякое прочее, я даже не силен в этом. Вы лучше знаете, упоминали об атрибутах на div элементах в других топиках.

johnd0e commented 1 month ago

Когда я писал "получившиеся блоки парсить как маркдаун" под блоками я имел ввиду то что содержится между открывающим и закрывающим тегом, а не содержимое самих тегов.