Исправление
commagray,
(текущая версия)
:
С подготовкой патча, наверное, дело затянется. Тупой вариант патча, оставляющий только Markdown, у меня есть, но он мне не нравится.
Дело в том, что lorsource скорее историческая свалка кода без особой документации и структурирования, чем какой-то самостоятельный движок форума (а ведь можно было причесать и предлагать людям вокруг, но это уже другая тема). С этим некоторые проблемы.
Markdown хоть и де-факто по умолчанию, но де-юре в движке нет состояния «стандартная разметка». Есть хардкод выбора Markdown как основной разметки при создании нового пользователя, конечно, но site-wide опции конфига, к которой можно обратиться из кода, нету.
Аналогично нет чёткого, отдельного неймспейса для новостей. Как детерминировать, что мы в разделе новостей? Ну, только у новостей бывают ссылки в теле поста, поэтому лепим if group!=null and group.linksAllowed then useMarkdownOnly. Тоже замечательно, ага.
Впрочем, при всей аляповатости исходников, может быть, моя правка не выглядит столь ужасной. По-хорошему мне бы хотелось сначала это отрефакторить, но такими темпами я увязну в попытках понять как работает Scala. =)
Конечно, инициатива этого голосования — краткосрочная мера, слабо влияющая на общую проблему. А она уже за пределами новостей.
Сосуществование Markdown и двух LORCODE, каждый из которых ведёт себя по-разному, является техническим долгом проекта. В лучшем случае у нас всё должно быть настолько единообразным, насколько возможно. Простым вариантом является удаление LORCODE, но на него всё ещё есть спрос — нужно что-то сложнее. И очень хорошо, что я полезла смотреть, что там в lorsource используется для Markdown. Используется Flexmark, в наименьшем своём виде реализующий спецификацию CommonMark, — и он крутой!
У меня вряд ли бы появились какие-либо идеи на пустом месте, но после прочтения документации к Flexmark и CommonMark можно обнаружить, что для первого очень просто пишутся плагины (в дереве исходников lorsource их несколько своих) и для внутреннего представления используется AST. Тут-то и щёлкнуло: а что если реализовать синтаксис LORCODE как один из парсеров Flexmark? Это максимально приближает нас к унификации, используя для разметки один и тот же инструмент, а не два разных.
Насколько я понимаю, это также позволит конвертировать LORCODE в Markdown и обратно. Что, скорее всего, потребует изменений в семантике LORCODE, чтобы приблизить её к совместимости с Markdown: пострадает работа отступов (никаких больше user line break — который, впрочем, всё равно deprecated), но все остальные теги должны будут работать как обычно. В любом случае что-нибудь кому-нибудь сломаю. =)
Осталось проверить, насколько реалистичен мой план.
Исправление
commagray,
:
С подготовкой патча, наверное, дело затянется. Тупой вариант патча, оставляющий только Markdown, у меня есть, но он мне не нравится.
Дело в том, что lorsource скорее историческая свалка кода без особой документации и структурирования, чем какой-то самостоятельный движок форума (а ведь можно было причесать и предлагать людям вокруг, но это уже другая тема). С этим некоторые проблемы.
Markdown хоть и де-факто по умолчанию, но де-юре в движке нет состояния «стандартная разметка». Есть хардкод выбора Markdown как основной разметки при создании нового пользователя, конечно, но site-wide опции конфига, к которой можно обратиться из кода, нету.
Аналогично нет чёткого, отдельного неймспейса для новостей. Как детерминировать, что мы в разделе новостей? Ну, только у новостей бывают ссылки в теле поста, поэтому лепим if group!=null and group.linksAllowed then useOnlyMarkdown. Тоже замечательно, ага.
Впрочем, при всей аляповатости исходников, может быть, моя правка не выглядит столь ужасной. По-хорошему мне бы хотелось сначала это отрефакторить, но такими темпами я увязну в попытках понять как работает Scala. =)
Конечно, инициатива этого голосования — краткосрочная мера, слабо влияющая на общую проблему. А она уже за пределами новостей.
Сосуществование Markdown и двух LORCODE, каждый из которых ведёт себя по-разному, является техническим долгом проекта. В лучшем случае у нас всё должно быть настолько единообразным, насколько возможно. Простым вариантом является удаление LORCODE, но на него всё ещё есть спрос — нужно что-то сложнее. И очень хорошо, что я полезла смотреть, что там в lorsource используется для Markdown. Используется Flexmark, в наименьшем своём виде реализующий спецификацию CommonMark, и он крутой!
У меня вряд ли бы появились какие-либо идеи на пустом месте, но после прочтения документации к Flexmark и CommonMark можно обнаружить, что для первого очень просто пишутся плагины (в дереве исходников lorsource их несколько своих) и для внутреннего представления используется AST. Тут-то и щёлкнуло: а что если реализовать синтаксис LORCODE как один из парсеров Flexmark? Это максимально приближает нас к унификации, используя для разметки один и тот же инструмент, а не два разных.
Насколько я понимаю, это также позволит конвертировать LORCODE в Markdown и обратно. Что, скорее всего, потребует изменений в семантике LORCODE, чтобы приблизить её к совместимости с Markdown: пострадает работа отступов (никаких больше user line break — который, впрочем, всё равно deprecated), но все остальные теги должны будут работать как обычно. В любом случае что-нибудь кому-нибудь сломаю. =)
Осталось проверить, насколько реалистичен мой план.
Исправление
commagray,
:
С подготовкой патча, наверное, дело затянется. Тупой вариант патча, оставляющий только Markdown, у меня есть, но он мне не нравится.
Дело в том, что lorsource скорее историческая свалка кода без особой документации и структурирования, чем какой-то самостоятельный движок форума (а ведь можно было причесать и предлагать людям вокруг, но это уже другая тема). С этим некоторые проблемы.
Markdown хоть и де-факто по умолчанию, но де-юре в движке нет состояния «стандартная разметка». Есть хардкод выбора Markdown как основной разметки при создании нового пользователя, конечно, но site-wide опции конфига, к которой можно обратиться из кода, нету.
Аналогично нет чёткого, отдельного неймспейса для новостей. Как детерминировать, что мы в разделе новостей? Ну, только у новостей бывают ссылки в теле поста, поэтому лепим if group!=null and group.linksAllowed then useOnlyMarkdown. Тоже замечательно, ага.
Впрочем, при всей аляповатости исходников, может быть, моя правка не выглядит столь ужасной. По-хорошему мне бы хотелось сначала это отрефакторить, но такими темпами я увязну в попытках понять как работает Scala. =)
Конечно, инициатива этого голосования — краткосрочная мера, слабо влияющая на общую проблему. А она уже за пределами новостей.
Сосуществование Markdown и двух LORCODE, каждый из которых ведёт себя по-разному, является техническим долгом проекта. В лучшем случае у нас всё должно быть настолько единообразным, насколько возможно. Простым вариантом является удаление LORCODE, но на него всё ещё есть спрос — нужно что-то сложнее. И очень хорошо, что я полезла смотреть, что там в lorsource используется для Markdown. Используется Flexmark, в наименьшем своём виде реализующий спецификацию CommonMark, и он крутой!
У меня вряд ли бы появились какие-либо идеи на пустом месте, но после прочтения документации к Flexmark и CommonMark можно обнаружить, что для первого очень просто пишутся плагины (в дереве исходников lorsource их несколько своих) и для внутреннего представления используется AST. Тут-то и щёлкнуло: а что если реализовать синтаксис LORCODE как один из парсеров Flexmark? Это максимально приближает нас к унификации, используя для разметки один и тот же инструмент, а не два разных.
Насколько я понимаю, это также позволит конвертировать LORCODE в Markdown и обратно. Что, скорее всего, потребует изменений в семантике LORCODE, чтобы приблизить её к совместимости с Markdown: пострадает работа отступов (никаких больше user line break — который, впрочем, всё равно deprecated), но все остальные теги должны будут работать как обычно.
Осталось проверить, насколько реалистичен мой план.
Исходная версия
commagray,
:
С подготовкой патча, наверное, дело затянется. Тупой вариант патча, оставляющий только Markdown, у меня есть, но он мне не нравится.
Дело в том, что lorsource скорее историческая свалка кода без особой документации и структурирования, чем какой-то самостоятельный движок форума (а ведь можно было причесать и предлагать людям вокруг, но это уже другая тема). С этим некоторые проблемы.
Markdown хоть и де-факто по умолчанию, но де-юре в движке нет состояния «стандартная разметка». Есть хардкод выбора Markdown как основной разметки при создании нового пользователя, конечно, но site-wide опции конфига, к которой можно обратиться из кода, нету.
Аналогично нет чёткого, отдельного неймспейса для новостей. Как детерминировать, что мы в разделе новостей? Ну, только у новостей бывают ссылки в теле поста, поэтому лепим if group!=null and group.linksAllowed then useOnlyMarkdown. Тоже замечательно, ага.
Впрочем, при всей аляповатости исходников, может быть, моя правка не выглядит столь ужасной. По-хорошему мне бы хотелось сначала это отрефакторить, но такими темпами я увязну в попытках понять как работает Scala. =)
Конечно, инициатива этого голосования — краткосрочная мера, слабо влияющая на общую проблему. А она уже за пределами новостей.
Сосуществование Markdown и двух LORCODE, каждый из которых ведёт себя по-разному, является техническим долгом проекта. В лучшем случае у нас всё должно быть настолько единообразным, насколько возможно. Простым вариантом является удаление LORCODE, но на него всё ещё есть спрос — нужно что-то сложнее. И очень хорошо, что я полезла смотреть, что там в lorsource используется для Markdown. Используется Flexmark, в наименьшем своём виде реализующий спецификацию CommonMark, и он крутой!
У меня вряд ли бы появились какие-либо идеи на пустом месте, но после прочтения документации к Flexmark и CommonMark можно обнаружить, что для первого очень просто пишутся плагины (в дереве исходников lorsource их несколько своих) и для внутреннего представления используется AST. Тут-то и щёлкнуло: а что если реализовать синтаксис LORCODE как один из парсеров Flexmark? Это максимально приближает нас к унификации, используя для разметки один и тот же инструмент, а не два разных.
Насколько я понимаю, это также позволит конвертировать LORCODE в Markdown и обратно. Что, скорее всего, потребует изменений в семантике LORCODE, чтобы приблизить её к совместимости с Markdown: пострадает работа отступов (никаких больше user line break, который, впрочем, всё равно deprecated), но все остальные теги должны будут работать как обычно.
Осталось проверить, насколько реалистичен мой план.