Хэш в блеклисте это вообще ничего не меняет, нужны же "сообщения от", если в файле эхи сообщение есть, то от него и пойдёт. Если хэша нет, то отдастся вся эха. По сравнению с текущим случаем, преимуществ два - хэш гораздо более надёжный источник, чем количество сообщений, и не сработает только в одном случае: если конкретная нода инъектировала в эху сообщения сверху - но на это нужно иметь настолько серьёзные основания, что это повод говорить об этом в сисопской эхе. Ну и второе - точно отдадутся только самые новые сообщения, одним запросом (я думал, реализация срезов вообще не так работает, в текущем виде она вообще какая-то непонятная, почему на все эхи один лимит, если сообщений в базе мало)

реализация и sf и lim у меня это всего несколько строчек.

было

def echoareas(names):
    out = ''
    for ea in names:
        out += ea + '\n' + get_echoarea(ea,True)
    return out

стало

def echoareas(names, sf, lim=0):
    out = ''
    if sf: sf = set(sf.split('/'))
    for ea in names:
        dllist = get_echoarea_f(ea)
        if sf:
            newhash = [x for x in dllist if x in sf]
            if newhash:
                dllist = dllist[dllist.index(newhash[0]):]
        if lim: dllist = dllist[-lim:]
        dllist = '\n'.join(dllist)
        if dllist: dllist += '\n'
        out += ea + '\n' + dllist
    return out

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

> Можно передавать уровни сокобана в plaintext-формате (.sok).

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

- если сообщений в базе мало
+ если новых сообщений в эхах разное количество, непонятно почему просто не запрашивать с каждой нужное (ну, или, с гарантией +1, +5 сообщений, это небольшой оверхед, по сравнению со случаем когда опращиваются одним запросом эхи с 1 и 110 сообщениями)
111
Вообще, связка h и sf реально сокращает количество запросов и реально экономит трафик. Если это кому-то важно.

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

Во-первых, формат. /u/e/ чётко определён, там перечисляются эхи. Почему не использовать что-то типа ?s=-100:100 или любой другой способ? Если в фетчер ii 0.3 просунуть такой формат url и запросить что-то с ii 0.3, фетчер упадёт, не растоссив пакет, потому что будет считать -100:100 хэшем сообщения. Зачем плодить неоднозначность просто на ровном месте, там, где есть куча способов её избежать?

Ладно, раз уж решили изнасиловать формат /u/e, почему не использовать /u/e/эха/срез/эха/срез. Это же для экономии трафика всё затевалось? А какая экономия, если у тебя может быть куча эх, и ради одной роботной, где всегда куча сообщений, тянется куча ненужных? А если поодиночке - то это лишние запросы, на медленном и нестабильном интернете каждый запрос это всегда больно, и он может даже не состояться (поэтому links решал там, где opera не могла ни одного сайта открыть). Формат /u/e был придуман ровно для того, что дёргать /e на каждую эху было медленно и неэффективно. Изначально были только /e и /m, но всё это было медленно и печально.

>>^^<><>>...<><>... я выиграл?

Ещё есть вариант найти мастера, сыграть в D&D.

P.S. Чур я бард-человек.

Не - ты делаешь ход посылая команду в эху, а некий бот верифицирует твой ход, модифицирует карту и посылает её обратно в эху в ожидании следующего хода…

кривая и косая версия adventure. играть можно только на моей станции

http://ii.blcat.ru/play.advent

по одному ходу скучно, надо сразу по много

тем более что sokoban игра с полной информацией и ходами только с одной стороны, её можно пройти одной командой

> Ещё есть вариант найти мастера,

тут новые пользователи появляются раз в пятилетку... :)

Складывается впечатление, что idec это пример плохого проектирования. Зачем менять устоявшуюся структуру запроса /u/e если можно этого не делать? Зачем вводить ограничение "количество сообщений в эхе может не совпадать со счётчиком", если можно этого не делать?

Формат /u/e был именно только для списка эх. Зачем добавлять туда что-то ещё? Почему не использовать, например /u/e?s=срез? Это значительно всё упрощает, это можно сувать куда угодно без разбора. А так алгоритм отдачи "всё эха" меняется на "последняя эха может быть не эхой":

ВЕСЬ ЗАПРОС СПИСОК ЭХ
ПОЛУЧИЛИ СПИСКИ
ЕСЛИ ЕСТЬ ЛИМИТ, УСТАНОВИЛИ

становится

ПОЛУЧИЛИ СПИСОК ЭХ
ПРОВЕРИЛИ ПОСЛЕДНЮЮ
ЕСЛИ ЭТО СРЕЗ, ТО РАСПАРСИЛИ СРЕЗ
СОХРАНИЛИ ЛИМИТ
УДАЛИЛИ ПОСЛЕДНЮЮ ЭХУ
ПОЛУЧИЛИ СПИСКИ
УСТАНОВИЛИ ЛИМИТ, ЕСЛИ ЕСТЬ

Команда lim появилась добавлением одного роута и одной строчки кода. Совместима с любым ii, хоть с ii-txt-0.1preprepre.

При этом корёжится список:
http://ii.blcat.ru/u/e/blcat.test/-100:100

ЧТО ТЫ ТАКОЕ? Эха? Нет точки, не эха. MSGID? по логике вроде бы да. У меня софт в расчёте на минималистичность и читаемость кода призван валиться при любых невалидных данных, а не разбираться, что это за ёжик.

Тут же появляется x/features. Это на каждый фетч надо ещё один запрос делать? Это не экономия трафика, это его расход. С какой-нибудь ?s= можно просто гонять url-ы и на любой клиент и на любой сервер, не задумываясь, поймёт ли он. А тут получается, надо прочитать x/features, потом подстроиться под сервера, давать ему срез или не давать. Лишний код, лишний трафик, лишнее переусложнение.

Сами же срезы не решают основной задачи "получить все нужные msgid одним запросом". Тебе нужно или обходить эхи по-очереди (привет, /e, от которого специально уходили для ускорения работы), или получать лишние сообщения. В стандарте не предусмотрено "хочу брать столько сообщений оттуда-то".

Кстати, ?sf потребовал добавления, по-моему, 4х строк кода и изменения одной. И он решает вопрос "получить только нужные msgid из нужных эх одним запросом".

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

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

ps. ?sf и ?h появились раньше, чем был сформирован стандарт iDEC.

добавил в архив сравнение станций

http://ii.blcat.ru:50000/compare

чёто боты по all=1 долбятся, сервер грузят, надо будет недоделанный архив скоро погасить, доделать, разобрать и перебрать

смотрю я на это и думаю, а давайте ru.humor.14 на бон вернём?

Не надо драматизировать :)

Индексы тоже пару строк кода добавляют (ну может чуть больше)

Для разнообразия можно множественные "слайсы" тоже сделать, типа

/u/e/echo.1/echo.2/-1:1/echo.3/-100:100/echo.4

будет означать, что echo.1 и echo.2 должны вернуть одно последнее сообщение, echo.3 должно вернуть 100 последних, а echo.4 должно вернуть всё - в этом случае всё будет логично и гибко ;)

Интересно, что ii.stat я взял с таверны, и сам добавляю туда еженедельную статистику, а там остался старый вариант остановившийся в 2018 году :)

Люди, дайте ii.14 у кого есть? Очень хочется в промежуточную историю окунутся между тем что было на alicorn и тем что сейчас - я письмо ake написал (у него на станции было), но он не отвечает...

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

> будет означать, что echo.1 и echo.2 должны вернуть одно последнее сообщение, echo.3 должно вернуть 100 последних, а echo.4 должно вернуть всё - в этом случае всё будет логично и гибко ;)

если менять это, то надо убирать неэхи из стрки для эх. чтобы оно прозрачно накладывалось, а не как у меня пишет -100:100 в файле списка, потому что на это вообще не рассчитвалась. в /u/e должны быть только эхи, это изначальный стандарт

Ещё момент - lor-opennet.17 есть в таверне тоже, только она там глючит (сразу после сбойного сообщение оно размножается)

> кто будет переписывать цезий или фетчеры под замену стандартов?

никто - сервер может поддерживать и ванильный ii без индексов, и старый IDEC где индексы в конце, и новый многоиндексный вариант - ничто ничему не противоречит!

> если менять это, то надо убирать неэхи из стрки для эх

очевидно, что запись [-]N:M не является эхой т.к. там не точка, а двоеточие (и может быть минус вначале)

> Индексы тоже пару строк кода добавляют (ну может чуть больше)

Ну ок не 2 строки, а 20, но тем не менее :)

elseif ($opts[0] == 'u' and $opts[1] == 'e') {
        $work_options=array_slice($opts, 2);
        $w_opts_count=count($work_options);

        if (
                $w_opts_count > 1 and
                strstr($work_options[$w_opts_count-1], ":")!==false
        ) {
                $buffer="";
                $numbers=explode(":", $work_options[$w_opts_count-1]);

                $a=intval($numbers[0]);
                $b=intval($numbers[1]);

                $echoareas=array_slice($work_options, 0, $w_opts_count-1);
                $messages=[];

                foreach ($echoareas as $echo) {
                        $slice = $access->getMsgList($echo, $a, $b);

                        if (count($slice) > 0) {
                                $buffer.=$echo."\n".implode("\n", $slice)."\n";
                        } else {
                                $buffer.=$echo."\n";
                        }
                }
                echo $buffer;

        } else {
                foreach($work_options as $echo) {
                        echo $echo."\n".implode("\n", $access->getMsgList($echo))."\n";
                }
        }
}

Это так в ii-php и я думаю не сильно сложнее будет поддержать "слайсы" в любом месте строки, а не только в конце...

Блин как эти ==== в этом ii-php работают? Ненавижу регулярные выражения...

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

Можно хоть xml регекспами парсить. Я спрашиваю зачем добавлять в список эх что то ещё, делать проверки которые можно было не делать, терять в прозрачности, если всё это можно было сделать кучей способов, каждый из которых лучше. Какую проблему решили добавив неэховую инфу в /u/e?

ahamai> Складывается впечатление, что idec это пример плохого проектирования.

На это я пытался намекнуть чуть ли не с первого дня появления здесь.

ahamai> MSGID? по логике вроде бы да.

Нет, в msgid тоже двоеточий быть не может. И длина должна быть 20 символов.

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

Я ещё могу понять, почему всё через / — это проще парсить, чем отдельно компоненты пути и компоненты HTTP query, особенно учитывая, что от HTTP в общем случае можно (и нужно) отходить. Но я не могу понять, почему бы не сделать в запросе такую же железобетонную структуру ключ-значение, как и в тегах бандла ii/ok/repto/blabla:

/u/e/echo.1/all/echo.2/-3:3/echo.3/-10:10

Этот формат (после удаления первого слэша) однозначно парсится в ключ-значение, на тикле он вообще одним сплитом преобразуется в список, читающийся через dict. И тогда и дополнительных проверок на то, где название эхи, а где диапазон, делать не нужно. Первый ключ — u со значением e, второй ключ — echo.1 со значением all и так далее. А сейчас всё как-то дико контекстозависимо получается, потенциал допустить ошибку куда выше.

У меня вообще в ноде на парсере нет регулярных выражений :)

Кстати я ошибся мой код ломает

Вечером напишу

revoltech> /u/e/echo.1/all/echo.2/-3:3/echo.3/-10:10

И да, в моём варианте вместо диапазона легко подставить msgid, и так же легко на стороне сервера проверить, что именно там стоит. Если диапазон, берём диапазон, если msgid, берём от этого msgid.

ahamai> Хэш в блеклисте это вообще ничего не меняет, нужны же "сообщения от", если в файле эхи сообщение есть, то от него и пойдёт. Если хэша нет, то отдастся вся эха. По сравнению с текущим случаем, преимуществ два - хэш гораздо более надёжный источник, чем количество сообщений, и не сработает только в одном случае: если конкретная нода инъектировала в эху сообщения сверху - но на это нужно иметь настолько серьёзные основания, что это повод говорить об этом в сисопской эхе.

Какие-то количества сообщений придумал. Нет их уже, считай. Легаси, который в скором времени выставим на мороз.

> Ну и второе - точно отдадутся только самые новые сообщения, одним запросом (я думал, реализация срезов вообще не так работает, в текущем виде она вообще какая-то непонятная, почему на все эхи один лимит, если сообщений в базе мало)

Как количество сообщений влияет на работу срезов? Out of range невозможен.

ahamai> не использовалось это никогда потому что я не вижу смысла экономить и так копеечный трафик. но на такой случай реализация в моей станции была

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

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

ahamai> Понятия не имею, что это слово означает, но вопросы имеются - раньше я вообще никогда не задумывался, как работают слайсы.
ahamai> Во-первых, формат. /u/e/ чётко определён, там перечисляются эхи.

Читай документацию внимательнее. Там не только эхи перечисляются.

ahamai> Почему не использовать что-то типа ?s=-100:100 или любой другой способ?

Мы и используем один из любых других способов.

ahamai> Если в фетчер ii 0.3 просунуть такой формат url и запросить что-то с ii 0.3, фетчер упадёт, не растоссив пакет, потому что будет считать -100:100 хэшем сообщения.

Почему у тебя фетчер считает имя эхи хэшем сообщения? Это явно что-то не так в ii 0.3. Зачем с аплинком на ii использовать то, что ii не умеет?

ahamai> Зачем плодить неоднозначность просто на ровном месте, там, где есть куча способов её избежать?

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

ahamai> Ладно, раз уж решили изнасиловать формат /u/e, почему не использовать /u/e/эха/срез/эха/срез.

Зачем?

ahamai> Это же для экономии трафика всё затевалось? А какая экономия, если у тебя может быть куча эх, и ради одной роботной, где всегда куча сообщений, тянется куча ненужных?

1. Ты тоже в максималисты подался? Затем, что лишних несколько сотен байт на фоне нескольких сотен килобайт это экономия трафика.

2. Ненужные сообщения не тянутся. Только новые. u/e, если ты забыл, даёт только индекс, но не сообщения.

ahamai> А если поодиночке - то это лишние запросы, на медленном и нестабильном интернете каждый запрос это всегда больно, и он может даже не состояться

И этот человек защищал кучу маленьких бандлов вместо всего в одном запросе.

ahamai> Формат /u/e был придуман ровно для того, что дёргать /e на каждую эху было медленно и неэффективно.

Однопоточный фетчер на срезах на перле, который тянет индекс по одной эхе и использует бандлы по 40 сообщений, утягивает клуб за 3 минуты. На медленном канале.

Он же, но с парой десятков сообщений новых сообщений работает 3-5 секунд.

Без новых сообщений он отрабатывает за 3-4 секунды.

ВНИМАНИЕ! Вопрос: куда ты так спешишь, что у тебя каждая секунда на счету?

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

>> Можно передавать уровни сокобана в plaintext-формате (.sok).
ahamai> это всё не так весело, тут играешь в одиночку. а я именно про игры всей компанией и совместную вовлечённость

Многие НРИ годятся для такого занятия. Всей гурьбой, увлекательно, разнообразно.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

ahamai> - если сообщений в базе мало
ahamai> + если новых сообщений в эхах разное количество, непонятно почему просто не запрашивать с каждой нужное (ну, или, с гарантией +1, +5 сообщений, это небольшой оверхед, по сравнению со случаем когда опращиваются одним запросом эхи с 1 и 110 сообщениями)
ahamai> 111
ahamai> Вообще, связка h и sf реально сокращает количество запросов и реально экономит трафик. Если это кому-то важно.

Оверхед меньше килобайта в подавляющем большинстве случаев. Это даже на 9600 бод можно не считать оверхедом. При этом ты предлагаешь более сложный и неработающий в части случаев вариант.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

tuple> Ещё есть вариант найти мастера, сыграть в D&D.

В общем случае неудобно. Карту надо и токены.

tuple> P.S. Чур я бард-человек.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Я честно пытался с тобой обсуждать, но ты, похоже, наркоман. Ты видишь то, чего нет.

За сим считаю, что обсуждение стандарта с тобой можно завершать. Какие счётчики? Какое скачивание лишних сообщений? Если ты не читал то, что я сюда приносил как черновик, то открой хотя бы исходники своего ii-0.3. Почитай на досуге. Сразу увидишь где ты неправ в своих претензиях. Ну а если не увидишь, то обсуждать с тобой дизайн, стандарт и реализацию тем более нет смысла.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

ahamai> смотрю я на это и думаю, а давайте ru.humor.14 на бон вернём?

У нас нет бона.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> Не надо драматизировать :)
shaos> Индексы тоже пару строк кода добавляют (ну может чуть больше)
shaos> Для разнообразия можно множественные "слайсы" тоже сделать, типа
shaos> /u/e/echo.1/echo.2/-1:1/echo.3/-100:100/echo.4
shaos> будет означать, что echo.1 и echo.2 должны вернуть одно последнее сообщение, echo.3 должно вернуть 100 последних, а echo.4 должно вернуть всё - в этом случае всё будет логично и гибко ;)

И это ломает поддержку стандарта.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

ahamai> кто будет переписывать цезий или фетчеры под замену стандартов? стандарты уже такие, какие получились. у меня вопрос - чому так?

Из стандарта выкидывается то, что по факту никому не нужно. Стандарты полностью совместимы с ii. Так что не понимаю твоего бухчения. Ты можешь взять хоть свой горячо любимый ii-0.3 и работать в сети полноценно.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

>> кто будет переписывать цезий или фетчеры под замену стандартов?
shaos> никто - сервер может поддерживать и ванильный ii без индексов, и старый IDEC где индексы в конце, и новый многоиндексный вариант - ничто ничему не противоречит!

Ну просто всё несовместимое снимается с фетча. Зачем нам поломанные узлы?

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> Блин как эти ==== в этом ii-php работают?

Это знает только автор. И то вряд ли вспомнит.

shaos> Ненавижу регулярные выражения...

Что может быть проще? Грамматики? Конечные автоматы?

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Предлагаю ввести общий слайсинг вида «ключ-значение», в котором вместо диапазона можно писать all или же msgid (в таком случае берётся содержимое эхо от него):

/u/e/echo.1/all/echo.2/some_msgid_blablabla/echo.3/-10:10

А ещё предлагаю ввести /u/mc, возвращающий число, чтобы клиент знал максимум сообщений, который нода может ему отдать за один GET-запрос /u/m.

AL> И это ломает поддержку стандарта.

Ладно. Ломает, так ломает, будем контекстозависимые парсеры городить. А что насчёт /u/mc?

revoltech> А ещё предлагаю ввести /u/mc, возвращающий число, чтобы клиент знал максимум сообщений, который нода может ему отдать за один GET-запрос /u/m.

Сейчас у меня в фетчере это значение по умолчанию равно 12, пока явно не указано обратное. Было бы неплохо, если бы станция сообщала эту информацию клиенту для оптимального выкачивания мессаг.

ahamai> Можно хоть xml регекспами парсить. Я спрашиваю зачем добавлять в список эх что то ещё, делать проверки которые можно было не делать, терять в прозрачности, если всё это можно было сделать кучей способов, каждый из которых лучше. Какую проблему решили добавив неэховую инфу в /u/e?

Проблему длинных индексов. Всё максимально прозрачно и понятно. Использование разных по смыслу значений в роутерах это нормальная практика. Посмотри хоть на ii. У тебя /u/e -- часть пути, которая определяет функционал. А параметры у неё что? Тоже часть пути. Зачем ты сделал эту неоднозначность?

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

ahamai>> Складывается впечатление, что idec это пример плохого проектирования.
revoltech> На это я пытался намекнуть чуть ли не с первого дня появления здесь.

Но ты всё ещё здесь. В интернете кто-т неправ? Или что?

ahamai>> MSGID? по логике вроде бы да.
revoltech> Нет, в msgid тоже двоеточий быть не может. И длина должна быть 20 символов.

ahamai просто не помнит свой же стандарт. Надеюсь, у него всё хорошо.

revoltech> Но в целом согласен, текущий формат слайсов какой-то недоработанный. Не то чтобы его сложно реализовать, но задачи экономить трафик при запросе большого количества эх он действительно не решает.

Ну да. Вместо выкачивания сотен килобайт мы выкачиваем сотни байт. Никакой экономии!

В общем, обсуждение не имеет смысла. По делу все высказались, рассуждения не по делу не имеют смысла.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Я про это тоже собирался вечером написать. Это было в bosfor

ну IDEC клиентов и серверов наклепали за 10 лет некоторое количество, поэтому и /u/e/echo.1/echo.2/echo.3 и /u/e/echo.1/echo.2/echo.3/-10:10 должны продолжать работать, а я предлагаю раширение, которое исправит последнюю претензию, что слайс распространяется на каждую эху из списка - будет возможность задавать разные слайсы на разные наборы эх в пределах одного запроса - чем плохо то? ;)

shaos> чем плохо то? ;)

Это не ко мне вопрос.

> Это знает только автор. И то вряд ли вспомнит.

Да там всё в коде - читай нехочу, но только без поллитры в этих регекспах не разрбраться (мне):

        for ($i = 0; $i < count ($string); ++$i) {
                $string[$i] = preg_replace("/([^\w\/])(www\.[a-z0-9\-]+\.[a-z0-9\-]+)/i", "$1http://$2",$string[$i]);
                $string[$i] = preg_replace("/([\w]+:\/\/[\w\-?&;%#~=\.\/\@]+[\w\/])/i","<a target=\"_blank\" href=\"$1\">$1</a>",$string[$i]);
                $string[$i] = preg_replace("/([\w\-?&;#~=\.\/]+\@(\[?)[a-zA-Z0-9\-\.]+\.([a-zA-Z]{2,3}|[0-9]{1,3})(\]?))/i","<a href=\"mailto:$1\">$1</a>",$string[$i]);
                $echo_check = preg_replace("/(.*)\<a target=\"_blank\" href=\"ii:\/\/(.+?)\"\>(.+?)\<\/a\>(.*)/", "$2", $string[$i]);
                if ($access->checkEcho($echo_check)) {
                        $string[$i] = preg_replace("/target=\"_blank\" href=\"ii:\/\/(.+?)\"/s", "class=\"iilink\" href=\"?echo=$1\"", $string[$i]);
                } else {
                        $string[$i] = preg_replace("/target=\"_blank\" href=\"ii:\/\/(.+?)\"/s", "class=\"iilink\" href=\"?msgid=$1\"", $string[$i]);
                }
                if (preg_match("/^====$/", $string[$i])) {
                        if (!$pre_flag) {
                                $pre_flag = true;
                                $string[$i] = preg_replace("/====/", "<pre>====", $string[$i]);
                        } else {
                                $pre_flag = false;
                                $string[$i] = preg_replace("/====/", "====</pre>", $string[$i]);
                        }
                }
                if(!$pre_flag && preg_match("/^\s?[a-zA-Zа-яА-Я0-9_\-]{0,20}(&gt;)+.+$/i", $string[$i])) {
                        $string[$i]="<span class='quote'>".$string[$i]."</span>";
                }

                if(!$pre_flag) {
                        $string[$i]=preg_replace("/(^|\s+)(PS|P\.S|ЗЫ|З\.Ы|\/\/|#).+$/i", "<span class='comment'>\\0</span>", $string[$i]);
                }
        }
        if ($pre_flag) $string[count($string) - 1] .= "</pre>";

ну разве что если /x/e/...

shaos> ну разве что если /x/e/...

Да пофигу, раз упростить алгоритмически всё равно ничего не получится, пусть будет так, как есть. Меня больше про /u/mc вопрос интересует.

> Что может быть проще? Грамматики? Конечные автоматы?

Мне проще на сях - перебираем строку посимвольно и делаём чо хотим...