Новый парсер LORCODE для топиков

конструкции вида [url=<url>][b]<text>[/b][/url] превращаются в [url]<url>[/url][b]<text>[/b] будем править или что то придумать? например разрешить в [url] кроме текста только [b]

Разрешите, пожалуйста, я в оформлении новостей этим пользуюсь. Или скажите, чтоб я так больше не делал, если жирная ссылка-название проекта выглядит некрасиво.
А также [i] [/i], [em] [/em] и [strong][/strong]. Остальные теги я лично не могу представить внутри текста ссылки.

Конструкция [b][url]http://www.yandex.ru[/url][/b] работает правильно. Из-за чего же, собственно, возник спор? Почему надо разрешать тег [b] внутри [url], ведь [b] вполне может быть частью этого самого URL?

это про конструкцию вида [url=....][b]...[/b][/url], а не когда ссылка внутри тега [url]

[b][url=http://www.yandex.ru]Яндекс[/url][/b][br]
[url=http://www.yandex.ru][b]ляндекс[/b][/url]

Яндекс
ляндекс
А, все, теперь понял, в чем проблема.
Но тогда уж надо по-разному обрабатывать [url]ссылка[/url] и [url=ссылка]текст[/url], причем во втором случае тогда уж разрешить все теги, какие сейчас есть, кроме [list], [quote], [code], самого [url] и, наверное, [br]

Новый парсер LORCODE

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

1. Casus,
   • вложенные
   • списки
   • делать
2. можно!

> Я был несказанно удивлён, узнав, что нельзя делать вложенные списки. В новом парсере так же нельзя?

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

хм, http://www.linux.org.ru/url , круть :-)

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

Я пробовал, но в предпросмотре первый же [ /list ] закрывал не второй, а самый первый [ list ]. Поэтому, использовал просто [ br ].

Посмотри, например, новость о новом ядре, там же список формировался ещё со старым парсером.

Посмотрел. Да, там вложенные списки. Впрочем, я писал не новость, а тему в L-O-R, которая про реформирование score, может в этом было дело? Точно помню, что не работали вложенные списки, по крайней мере при предпросмотре. Я обошёлся без них.

нет! логика другая - комментарии и топики которые накарябал пользователь с кол-вом звезд >= 2 отображается новым парсером иначе старым, то есть к примеру ананимус видит тоже самое что и мы

А как насчет фиксированной высоты блока [code] с прокруткой содержимого? А то иногда такие длиннючие простыни бывают...

Это ужасно. Длинные простыни должны быть на pastebin'е.

А вот и нет. Почему это ЛОР должен в плане форматирования зависеть от стороннего ресурса?

Ну и представьте: нашли вы решение какой-то проблемы на ЛОРе, а конфигурационный файл был помещен на pastebin сроком хранения месяц. И фигвам получается...

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

ах да, в новом парсере для топиков есть тэг [cut] только не известно включен ли он, его имеет смысл пользовать в новостях

Не работает

видно(вернее невидно) только в новостях. пример: http://lor.vyborg.ru/news/ первая новость, первая ссылка «Подробности».

Но тэг схавывается. Может только в предпросмотре не работает?

Вот что я выше писал:

 
  <div id="cut0"></div><p>Не работает
</p>
    <div class="sign">
...

скрытие работает только в новостях когда они отображаются лентой

интересно, если сейчас подредактировать, например, свежую новость о KDE, добавив тэг cut, сколько будет ненависти? :-)

Маленький вопрос:

Если писать так:

⦍code⦐
#include <stdio.h>
⦍/code⦐

То выглядит это так:

#include <stdio.h>

Заметьте лишнюю пустую строку перед #include

Это видимо с точки зрения html, потому что ⦍code⦐ сразу меняется на <pre> в html, но мне кажется немного неэстетично. Это я зануда, и это фича, или можно поправить?

Я могу, чё, мне уже нечего терять. :)
Кстати, только что заметил досадную неприятность:
Я писал

http://www.linux.org.ru/[b]news/kde[/b]/6543639

горя желанием выделить часть ссылки

УБИВАТЬ! НЕНАВИСТЬ! СМЕРТЬ ЧЕЛОВЕКАМ!

http://www.linux.org.ru/news/kde/6543639

незашто

>Заметьте лишнюю пустую строку перед #include
не замечаю, это css такой я щитаю

>для топиков тех, у кого две и более зеленые звезды.

habra-way — no way!

Ты не понял, я не хотел, чтоб она вставилась как ссылка.

хе :-) за-то авто-подсветка ссылок работате

Ну да, я заметил :(
А как сказать парсеру, не преобразую http://text в ссылку?

я не вижу как

Ну вот :(
http://test http://test http://тест

>http://тест

это уже вопрос к рэгекспу старенькому который определяет что url это url

ну эт-то ясно. ладно.

Нда, оказывается проблема комплексная.

Во первых,

www.linux.org.ru/white2/combined.css

--- combined.css.old	2011-07-27 16:56:05.000000000 +0200
+++ combined.css	2011-07-27 20:21:52.000000000 +0200
@@ -33,7 +33,7 @@
 DIV.notes{text-align:center;font-style:italic;margin-top:.5em;margin-bottom:.5em;border:solid black}
 .nav A{text-decoration:none}
 .bluehead{background:#defefc}
-pre code{display:block;color:#000}
+pre code{color:#000}
 pre .subst,pre .title{font-weight:normal;color:#000}
 pre .comment,pre .template_comment,pre .javadoc,pre .diff .header{color:#808080;font-style:italic}
 pre .annotation,pre .decorator,pre .preprocessor,pre .doctype,pre .pi,pre .chunk,pre .shebang,pre .apache .cbracket{color:#808000}

Но, во-вторых, это работает похоже только для opera! FF и konqueror (а хромиума у меня нет) всё равно показывают это так:

 

blabla

вместо

blabla

вообще white2 барабашковая тема, мы к примеру так и не решили баг с окантовкой: https://www.linux.org.ru/forum/linux-org-ru/6499181

Надо будет мне может пересмотреть css, как время будет. Главное не убирать white2 совсем :)

Но я ещё имел в виду, что мой псевдобаг имеет место и в tango, по крайней мере в firefox и konqueror. У тебя же вроде опера.

>с прокруткой содержимого

Нет! Пожалуйста, нет! Только не это! Это же ужасно неудобно!

хм, а если после [code] не делать перенос строки то получается:

--- combined.css.old	2011-07-27 16:56:05.000000000 +0200
+++ combined.css	2011-07-27 20:21:52.000000000 +0200
@@ -33,7 +33,7 @@
 DIV.notes{text-align:center;font-style:italic;margin-top:.5em;margin-bottom:.5em;border:solid black}
 .nav A{text-decoration:none}
 .bluehead{background:#defefc}
-pre code{display:block;color:#000}
+pre code{color:#000}
 pre .subst,pre .title{font-weight:normal;color:#000}
 pre .comment,pre .template_comment,pre .javadoc,pre .diff .header{color:#808080;font-style:italic}
 pre .annotation,pre .decorator,pre .preprocessor,pre .doctype,pre .pi,pre .chunk,pre .shebang,pre .apache .cbracket{color:#808000}

white2 не уберут если им будут пользоватся

Это удобнее, чем листать сообщения с длиннючими листингами.

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

Это будет намного лучше, чем скакать по ссылкам на pastebin.

упс я оказывается зацепил за одно еще один тэг [pre]:

Тег используем мы этот,
Чтобы строки разделять,
Если вдруг стихи захочем
Здесь, на ЛОРе, запощать.

Ну а строфы разделяем
Как привыкли уж давно!

(c) Eddy_Em

http://test

http://test

Разница очевидна, да.

        //Тэги в которых разрешен автоматическое выделение ссылок
        autoLinkTags = ImmutableSet.of("b", "i", "u", "s", "em", "strong", "p", "quote", "div", "cut");

добавить сюда pre и будет видна разница

Я даже теряюсь: ответить "nooooooooooooooo!!!" или «Даааа, сделай это!..» :3