>>/b/1003098
Раньше не было возможности escape-ить символы разметки, теперь есть.

Раньше на ***%%You are a buggy fork!%%*** Кусаба выводила ломаный HTML, <b><i><spoiler></spoiler></b></i>, ибо ** имеет приоритет над *, и возник вопрос, что делать в ситуации, когда встречаем тэг, закрывающий блок верхнего уровня, а внутренние блоки ещё не закрыты.
A.   Закрывать все внутренние блоки по тэгу закрытия блока верхнего уровня. ***%%*** => <b><i><spoiler></spoiler></i></b><i>;
A++. По закрытию, восстанавливать незакрытый внутри закрываемого блока контекст. ***%%*** => <b><i><spoiler></spoiler></b><i></i>;
B.   Сделать приоритет тэгов разметки контекстно-зависимым, чтобы ***%%You are a buggy fork!%%*** интерпретировалось как [b][i]%%You are a buggy fork!%%[/i][/b]. Или ***%%*** => <b><i><spoiler></spoiler></i></b>

Вариант A позволяет написать You are a buggy fork! как ***%%You are a buggy fork!**, что короче и потенциально удобнее. Варианты A++ и B имитируют, как было раньше.
Вариант A было меньше кодить, потому и был реализован. Но, если нужно, могу к началу января взяться сделать совместимость. Который из вариантов больше по душе?

>>1000358
Поспав на этом два дня, думаю, что можно, технически, просто добавить пример со спойлером в раздел Markdown->Особенности (и поставить туда якорь, чтобы ссылаться удобнее).

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

Я попробую потыкать до рождества и сам и его что кому надо.

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

>>1000368
> И тогда Совусу наверное захочется совместимость
Скорее всего. A++ вариант к нему ближе всего. Кусаба parse'ит ***Жирный**Курсив* как ЖирныйКурсив, after all.

Хотя не идентичен: скажем, **text* Кусаба распарсит как *text, но не текущий алгоритм. Чтобы, как Кусаба, нужно вводить lookahead до закрывающего тэга. Который ещё может оказаться в [nofmt] блоке, и который должен будет игнорироваться поэтому. И который если не найдётся, должен будет привести к reparsing'у того would-be открывающего ** как *.
> и чтобы теги не закрывались по концу сообщения а игнорировались наверное
И это тоже. И тут тоже нужно искать закрывающий тэг. В любом случае, похоже, стоит отказаться от parsing'а в один проход. Скажем, можно разбить ввод на токены, инактивировать незакрытые тэги, убрать пустые блоки, и уже потом делать HTML. Можно сделать и lookahead-зависимый **/* parsing, но это куда муторнее.

> можно придумать вообще кнопку текстового превью поста?
Why not. Если силы есть.
> или переписывать то же самое по второму разу
Даёшь Flower Bus на Node.js!

>>/b/1003427
> 300x100
Поднимаем баннер?

>>1000377
Сначала пусть кто-то нарисует.

>>1000378
??

>>1000377
Миленько, но кто это там на самолёте?

>>1000380
Pea Ace (Горошина-Ас) же!

Пытались что-нибудь трогать?

> И который если не найдётся, должен будет привести к reparsing'у того would-be открывающего ** как *
Любопытная циклическая лабуда в оригинальной Кусабе.

'' => '';
'*' => '*';
'**' => '**';
'***' => '*';
'****' => '**';
'*****' => '*';
'******' => ''; // <b><i></b></i>

Если приставлять звёздочки к 'text*' и 'text**' период тоже 6, но свой.

Наверное, нет смысла такое поведение копировать? А то как бы не получилось, что последовательное применение регулякок со strtr-ом выйдет не только на несколько сотен строк кода меньше, но и быстрее.

Пускай, наверное, будет '****' => '', то бишь <b></b>. В конце концов, оригинальный parser не убирает возможность отправить пустое сообщение, either. Тогда, пусть будет '***' => '***', '***t*' => '**t' '***t**' => '*t' и '***t***' => 't'. Пустые же блоки дополнительным проходом поубирать.

Стоит сделать обновление RSSа по удалению поста. >>/b/1003583

>>1000385
Что там обновлять?
Если такое сообщение попало в кеш твоего ридера то сервер с ним уже ничего не сделает.

>>1000385
Done.

>>1000386
RSS обновлялся только по постингу новых постов.

>>1000370
Силы на это нашлись, прикрутить перевод после нескольких попыток не нашлись.

>>1000377
Done.

>>1000383
Если '****' это <b></b>, то почему *** не <i>*</i>?
Алсо, '***t**' => '<b>*t</b>' или *<b>t</b>? По идее наверное первое?

> Done.
Cool.

>>1000389
> почему *** не <i>*</i>?
У позиции 0 распознаётся **, поскольку имеет приоритет над *, и parsing идёт дальше. У позиции 2 * распознаётся как *, но ни для раннего **, ни для * не находится закрытие. Поэтому оба инактивируются и печатаются, как есть. Reparsing'а у позиции 0 не происходит. Если бы происходило, было бы <i></i>*, и было бы '**' => ''.

> По идее наверное первое?
Да.

Если саму систему parsing-а пока не трогали, напишу новый BBCode() тогда. Где-то к началу января будет готово.

Как-то так пока вижу.
Оставляем continue-проверки только для кода/nofmt и для \n\r-тэга закрытия списка, а также для открывающего BB-тэга, если ровно тот же тэг пока не был закрыт, i.e. в '[i] [i] [/i]' второе [i] вызывает continue, '[i] [i] [/i]' => ' [i] '.

Встречаем тэг? Добавляем его в список, а также простой текст между ним и предыдущим тэгом. Вместо true в $states пишем ссылку на свежедобавленный элемент списка. Встречаем закрывающий тэг? Из $states, если есть, по ссылке достаём соответствующий открывающему тэгу элемент списка, и прописываем туда ссылку на закрывающий элемент. Вторым проходом инактивируем незакрытые тэги, третьим делаем HTML, следя, чтобы '* [i] test * [/i]' и подобное не приводило к некорректному HTML: '* test0 [i] test1 * test2 [/i]' => ' test0 test1 test2 '.

> к началу января
Или к середине.

>>1000391
Да это я думаю пока не критично, хоть и хорошо было бы.

Я сам-то в разъездах до 12го.

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

>>1000402
Не совсем понимаю, как это читать. Это всё местное, и заодно течёт не только воркер? Ну и на всякий случай тот же вопрос про 410.

Так-то я могу себе вернуть/поставить тоже рикай и помониторить.

>>1000403
Я тоже не понимаю, как это читать, лол.
Эото скриншоты с девтулсов, открытых на вкладке именно тут. Просто тыкнул что-то с надписью memory как очевидное, а там почему-то экстеншоны. Воркера не видно было, но единственное отличие 0141 от 014 в нём, поэтому на него и грешу.
Вот сейчас рикая нет, а вкладка опять 200,000 K и растёт дальше пока пишу этот пост.

Открыл /b/ 410 сейчас, прокрутил сверху донизу, открыл quick reply, попечатал, развернул картинку на 4000×4000, подождал. Около 70,000 K, стабильно, (норма).
Быстрый тест булки (поставил sleep 5m) - так же.

Попробовал Clear site data в Devtools (и Unregister service workers которая там). Всё равно отъелась до 400,000K просто постояв открытая.

В общем, мистика.

Сделать тут мало что можно, так как подозреваю всё-таки какую-то непонятную несовместимость с моей уникальной конфигурацией. Но мне хотелось бы узнать, сколько у вас вкладка потребляет просто постояв. Может, у вас много памяти свободно и вам просто незаметно. А я тут постоянно на границе OOM сижу. Месяц непрерывно запущенного хрома это не шутки, собсно, там сам Browser утекает, а кнопки Minimize mem usage, как в Firefox, не завезли.

Как-то так на моей лисе. Наверное, действительно течёт где-то.

>>1000404
> но единственное отличие 0141 от 014 в нём
Не единственное же. Есть изменения в kusaba.js.

>>1000405
Это очень долгий замер! У меня за пять минут все улетает. Ну и в "лисе", а надо на хромиум-подобных!

>>1000406
Или не течёт. Проверю в хромиуме чуть позже.

На TaskManager-е в Хромиуме memory footprint действительно растёт, но и периодически сбрасывается. Наверное, дело в сборке мусора.

Memory Snapshot за 5 минут, однако, ничего интересного не показывает.

>>1000391
Новости.

У меня депрессия.
tokenize → fix_integrity → print почти готово, оставалось бы только отдебажить, но поскольку [nofmt] и [code] сами по себе являются escaper'ами, для них нужно будет делать предобработку отдельным циклом и таки с lookahead'ом, и уже потом дотокенезировать гарантированно непокрытый активными [nofmt] или [code] блоками текст. Завис пока на этом.

Иначе, как пока сейчас у меня в черновике, будет вывод «every mark after unclosed ` is **ignored** ». А должно быть «every mark after unclosed ` is ignored"».

Also, погодя возник вопрос, что делать, если, скажем, для незакрытого [code] встречаются за-escape'ленные и escape-блоком другого типа, и тильдою [/code], например «[code] This is `NOW ~[/code]`». Думаю резолвить такой ввод как «[code] This is NOW ~[/code]» всё-таки.

Другие заметки по надвигающемуся.

Будет пофикшена ситуация (±костыльно, но можно будет включить и цитирование в обобщённую обработку)

• List end.

> Citation

Будет пофикшена ситуация

%%
- Bug.
%%

↓↓↓↓↓↓↓

• Bug.

>>1000410
Поправляйтесь.

Ради развлечения, попробовал чисто теоретически сформулировать грамматикой. Выходит как-то не очень:

Message => List\nMessage|Quote\nMessage|Paragraph\nMessage|EOF
List => OrderedList|UnorderedList
OrderedList => OLElement\nOrderedListContinuation|OLElement
OrderedListContinuation => OLElement\nOrderedListContinuation|OLElement
OLElement => +InlineParagraph|#InlineParagraph
UnrderedList => ULElement\nUnorderedListContinuation|ULElement
UnorderedListContinuation => ULElement\nUnorderedListContinuation|ULElement
ULElement => -InlineParagraph|*InlineParagraph
InlineParagraph => Line|Line~\nInlineParagraph
Line => NoFmtLine,Line|CodeLine,Line|BoldLine,Line|ItalicLine,Line|UnderscoreLine,Line|StrikethroughLine,Line|AsciiLine,Line|SpoilerLine,Line|URL,Line|Text,Line|<empty>
NoFmtLine => [nofmt]Text,NoEscape[/nofmt]|``Text,NoEscape``
CodeLine => [code]Text,NoEscape[/code]|`Text,NoEscape`
BoldLine => [b]Line,NoEscape[/b]|**Line,NoEscape**
ItalicLine => [i]Line,NoEscape[/i]|**Line,NoEscape**
UnderscoreLine => [u]Line,NoEscape[/u]
StrikethroughLine => [s]Line,NoEscape[/s]|^^Line,NoEscape^^
AsciiLine => [aa]Line,NoEscape[/aa]
SpoilerLine => [spoiler]Line,NoEscape[/spoiler]|%%Line,NoEscape%%
NoEscape => (~~)*|Text,(~~)*
Text => [^\n]*?
URL => (http|https|ftp|sftp|mailto)://[^, \n]+
Paragraph => NoFmtParagraph,Paragraph|CodeParagraph,Paragraph|BoldParagraph,Paragraph|ItalicParagraph,Paragraph|UnderscoreParagraph,Paragraph|StrikethroughParagraph,Paragraph|AsciiParagraph,Paragraph|SpoilerParagraph,Paragraph|Line,Paragraph|<empty>
NoFmtParagraph => [nofmt]MLText,NoEscape[/nofmt]\n?
CodeParagraph => [code]MLText,NoEscape[/code]\n?
BoldParagraph => [b]\n?Paragraph\n?,NoEscape[/b]\n?
ItalicParagraph => [i]\n?Paragraph\n?,NoEscape[/i]\n?
UnderscoreParagraph => [u]\n?Paragraph\n?,NoEscape[/u]\n?
StrikethroughParagraph => [s]\n?Paragraph\n?,NoEscape[/s]\n?
AsciiParagraph => [aa]\n?Paragraph\n?,NoEscape[/aa]\n?
SpoilerParagraph => [spoiler]\n?Paragraph\n?,NoEscape[/spoiler]\n?
MLText => Text\nMLText|Text|\n|<empty>

Хорошо что мы вложенные списки пока не даём.

>>1000411
А, ну и >>ссылки забыл добавить на одном уровне с урл и определить Quote как >Line. (или InlineParagraph?)

>>1000410
Готово. parse.class.php и markdown.html в архиве. Запилено, как оговорено, Кусаба-подобное поведение, пофикшено упомянутое в >>1000410 и >>/b/1004023 пофикшено тоже.

Обработка (">", "\r\n") обобщённым токенизатором привела к конфликту с >>post_id, который был решён запихиванием обработки этого >>post_id в общий же токенизатор: как следствие, внутренние ссылки теперь подлежат escape-у. Возможно, стоит запихать в него же и обработку внешних ссылок, что может быть удобно, если хочется поместить ссылку под спойлер. InterboardQuoteCheck и InterthreadQuoteCheck я не трогал.

Наверное, можно как-то красиво сжать определения констант, но я не стал заморачиваться.

Часть debug_* функций я не стал удалять. Вдруг пригодятся.

> Поправляйтесь
Спасибо.

> чисто теоретически сформулировать грамматикой
Тоже вот думалось, можно ли как-то это дело формально определить и скормить Bison-у, и чтобы оно само всё сгенерировало. Но у нас, вполне возможно, не context-free grammar.

> Хорошо что мы вложенные списки пока не даём
Scary.

>>1000413
It's up!

>>1000410
Мужик сказал — мужик сделал. Круто и ответственно!