Здравствуйте, Tuo_Bellas, Вы писали:
J>>>да просто добавьте спановый тег типа fixed или monospace — и уже будет гораздо лугче
J>>Ну что, предложение не прошло?
T_B>Да-а, что-то все заглохло. Жалко. ((
Хотя... здесь
T_B>Да, еще хотелка: хочу параметр title к тегу [/q]. Чтобы можно было писать
T_B>[/q title="From MSDN:"] T_B>blah blahblah blahblah blahblah blahblah blahblah blahblah blahblah blahblah blahblah blahblah blahblah blahblah blahblah blahblah blahblah blah T_B>[/q]
T_B>И получалось бы что-то типа
T_B>
То есть, хочу опционально приписывать к цитате заголовок -- все равно почти всегда есть необходимость писать название или источник информации.
Еще вспомнил. Хочу шапку к тексту с тегом [code] и производным к ним со ссылкой "копировать в буфер". Как сделано на www.gamedev.ru. Или лучше внизу справа дать ссылку:
Hello, adontz!
a> набрав [list=3] я получил список элементы которого нумеруются с трёх. a> Очень удобно когда хочешь продожить список. Так же давно уже пора
Это уже давно есть. Ты попробуй [list=3], [list=a], [list=I].
Из эстетических соображений хочу тэг, чтобы выделять участки кода, содержащиеся прямо в тексте. Цветом и/или фоном и/или шрифтом или как-нибудь еще. Раскраска не обязательна.
Пример:
void foo();
int bar();
float baz();
В этом абзаце я пишу о функциях foo(), bar() и baz(). Хочу видеть их имена отличающимися от текста. Просто выделение жирным и/или курсивом это немножко не то . В текстах с пропорциональным шрифтом такие вещи обычно выделяют фиксированным.
Спасибо.
Tuo_Bellas.
P.S. Я, конечно, понимаю, мы не можем эмулировать TEX... А жаль...
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Tuo_Bellas, Вы писали: S>Дело хорошее. Вот только геморройное. Дублировать всю раскраску — самоубийство, у нас в два раза вырастет количество тэгов. Просто заменить в форматтере див на спан — исковеркать большое количество сообщений. В общем, сомнения смутные терзают. Попробуем убедить кого-нибудь из рулевых потестироваться.
да просто добавьте спановый тег типа fixed или monospace — и уже будет гораздо лугче
Здравствуйте, IT, Вы писали:
IT>А потом все пользователи януса получать гигабайт сообщений при следующей синхронизации.
Во-первых далеко не все сообщения содержат коды форматирования, а во-вторых этот процесс можно запросто растянуть во времени поддерживая 4-6 месяцев оба вида кодов форматирования, но разрешая вводить только новые.
Плюс такого дела — многие получат в Янус почти полную БД сообщений (а с дополнением оборванных веток ну совсем почти полную.) Смотри на вещи оптимистичнее. Если в день придётся качать не 200, а 600кб от этого некто не умрёт. И потом, кто сказал, что гиг? Сейчас 600 тыс сообщений. Если в среднем по 1кб на сообщение (янус ведь берёт именно текст, а не HTML и форматирует уже на месте), то это пол гига. А с учётом того, что далеко не всё форматированно, на самом деле мегабайт 100. Растяни это на 3 месяца, по 1мб в сутки лишний. Если ещё и по суткам растянуть (2-4 раза в сутки) то никто и не заметит ничего. Растяни на пол-года, лишних 500кб/день никто и не заметит! Более того если сделать сервис который будет с указанной скоростью (сообщений/мин) конвертировать сообщения, то нагрузка будет ну совсем равномерной.
Так что не пугай народ!
Здравствуйте, adontz, Вы писали:
S>>вот я и говорю — удвоится количество тегов.
A>С какой стати? Разве нельзя в УЖЕ существующих сообщениях просто заменить старые теги на новые? Туту конечно не простой запрос, да и вряд ли только SQL обойдётся (хотя можно поизвращатся), но надо отрабатывать 2-х процессорный сервер
Нет, я точно ничего не понимаю. А просто добавить один (1) новый тэг нельзя? А старые не трогать.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, IT, Вы писали:
IT>>А потом все пользователи януса получать гигабайт сообщений при следующей синхронизации.
A>Во-первых далеко не все сообщения содержат коды форматирования, а во-вторых этот процесс можно запросто растянуть во времени поддерживая 4-6 месяцев оба вида кодов форматирования, но разрешая вводить только новые.
A>Плюс такого дела — многие получат в Янус почти полную БД сообщений (а с дополнением оборванных веток ну совсем почти полную.) Смотри на вещи оптимистичнее. Если в день придётся качать не 200, а 600кб от этого некто не умрёт....
Спасибо, благодетель. Выбирая небольшую часть форумов, я каждый день качаю дома по диалапу полтора мега. Предлагаешь качать 5? Нафиг-нафиг такой геморой из-за одного тега. Потом кто-то придумает еще один тег, и все по новой? Ради сомнительной красоты форматирования одного слова в тексте?
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
[/ccode]
void foo();
int bar();
float baz();
[/ccode]
... << RSDN@Home 1.1.3 beta 1 >>
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
[/ccode]
void foo();
int bar();
float baz();
[/ccode]
... << RSDN@Home 1.1.3 beta 1 >>
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Да нет, я не этот текст хочу выделить. Тот, что в тексте. Чтобы можно было написать в тексте абзаца, скажем [/ccode]foo[/ccode], и не начиналась новая строка как сейчас:
Здравствуйте, Tuo_Bellas, Вы писали:
Дело хорошее. Вот только геморройное. Дублировать всю раскраску — самоубийство, у нас в два раза вырастет количество тэгов. Просто заменить в форматтере див на спан — исковеркать большое количество сообщений. В общем, сомнения смутные терзают. Попробуем убедить кого-нибудь из рулевых потестироваться.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Дело хорошее. Вот только геморройное. Дублировать всю раскраску — самоубийство, у нас в два раза вырастет количество тэгов. Просто заменить в форматтере див на спан — исковеркать большое количество сообщений. В общем, сомнения смутные терзают. Попробуем убедить кого-нибудь из рулевых потестироваться.
Естественно нужен новый тэг. Не [ccode].
Можно и без раскраски. Куски кода в абзацах обычно небольшие, расскрашивать не очень много. Хотя бы просто Courier на сером фоне -- и то хорошо.
А для раскраски можно прикрутить опциональный параметр тэга с именем языка. Типа [ic] -- аналог [code], [ic lang="c"] -- аналог [ccode], [ic lang="pascal"] для паскаля и т.п. Если архитектура форматтера поддерживает.
Здравствуйте, Tuo_Bellas, Вы писали: T_B>А для раскраски можно прикрутить опциональный параметр тэга с именем языка. Типа [ic] -- аналог [code], [ic lang="c"] -- аналог [ccode], [ic lang="pascal"] для паскаля и т.п. Если архитектура форматтера поддерживает.
вот я и говорю — удвоится количество тегов. T_B>Tuo_Bellas.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
T_B>>А для раскраски можно прикрутить опциональный параметр тэга с именем языка. Типа [ic] -- аналог [code], [ic lang="c"] -- аналог [ccode], [ic lang="pascal"] для паскаля и т.п. Если архитектура форматтера поддерживает. S>вот я и говорю — удвоится количество тегов.
Тогда я чего-то не понимаю. Тэг это "ic". А "lang" это параметр тега.
Я правильно понимаю, что основная причина бояться увеличения числа тегов -- увеличение числа записей в тулбаре внизу?
Тогда просто можно сделать там один тэг [ic] без параметров. А про параметры написать в тултипе, что они есть (типа "можно указать язык для подсветки в параметре lang"). Кому надо, тот руками допишет lang="c" или "java". Я, например, вообще почти этим тулбаром не пользуюсь.
К тому же, в большой части случаев все равно подсветка от изменения языка не будет сильно изменяться (ср. void foo() в c, java и c# например). Этим тегом, повторюсь, подсвечиваться будут в основном короткие участки текста.
Здравствуйте, Sinclair, Вы писали:
S>вот я и говорю — удвоится количество тегов.
С какой стати? Разве нельзя в УЖЕ существующих сообщениях просто заменить старые теги на новые? Туту конечно не простой запрос, да и вряд ли только SQL обойдётся (хотя можно поизвращатся), но надо отрабатывать 2-х процессорный сервер
Здравствуйте, adontz, Вы писали:
A>С какой стати? Разве нельзя в УЖЕ существующих сообщениях просто заменить старые теги на новые? Туту конечно не простой запрос, да и вряд ли только SQL обойдётся (хотя можно поизвращатся), но надо отрабатывать 2-х процессорный сервер
А потом все пользователи януса получать гигабайт сообщений при следующей синхронизации.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, adontz, Вы писали:
A>Более того если сделать сервис который будет с указанной скоростью (сообщений/мин) конвертировать сообщения,
Чтоб за 6-8 месяцев сконвертировать всю БД нужна скорость 2.5 сообщения в минуту. Сейчас средняя скорость поступления новых сообщений 1 сообщение в минуту. Увеличение нагрузки на Янус при таком режиме будет в 3.5 раза. Веб интерфейсу будет ясное дело плевать (или нет?) Кстати что случится вс NNTP?
Предлагю открыть голосование, ИМХО дело хорошее...
Здравствуйте, Tuo_Bellas, Вы писали:
T_B>Нет, я точно ничего не понимаю. А просто добавить один (1) новый тэг нельзя? А старые не трогать.
Можно, но это тупиковый путь развития. Правильный путь, это тег [code], который не включает в себя автоматически переносы строк в начале и конце и поддерживает язык как параметр. То есть не [ccode], [vb], [java], а [code=c], [code=vb], [code=java]. Причём тег воспринимается не целиком, а именно как тег с параметром.
Точно так же как тег [list] давно пора сделать вкладываемым (сейчас 2 списка один в другом не делается) и параметризированным. То есть, чтобы набрав [list=3] я получил список элементы которого нумеруются с трёх. Очень удобно когда хочешь продожить список. Так же давно уже пора распознавать списки в таком виже
1)
2)
3)
а)
б)
в)
Потому что они быстрее набираются (код для обозначения пункта был выбран крайне неудачно. Надо или шёлкать мышью, то есть отрывать руку от клавиатуры, либо переключатся в английскую раскладку и потом опять в русскую, что тоже неудобно).
Распознавать можно по запросу (как есть checkbox отключить смайлики, можно сделать checkbox — отключить распознавание списков).
При такой модернизации поддерживать старые коды просто неудобно.
Здравствуйте, der Igel, Вы писали:
DI>Это уже давно есть. Ты попробуй [list=3], [list=a], [list=I].
Да ну? А чё мочали? А вот распознавание списков
1)
2)
3)
Если сделать, то будет вообще офигительно! Ну подмай сам, набирать в русской раскладке это ужас!
Здравствуйте, adontz, Вы писали:
T_B>>Нет, я точно ничего не понимаю. А просто добавить один (1) новый тэг нельзя? А старые не трогать.
A>Можно, но это тупиковый путь развития. Правильный путь, это тег [code], который не включает в себя автоматически переносы строк в начале и конце и поддерживает язык как параметр.
[...]
Это все, конечно хорошо, и я, конечно, за. Но это все "потом и не скоро". А мне хочется "сейчас и сразу".
Здравствуйте, Kupaev, Вы писали:
K>Спасибо, благодетель. Выбирая небольшую часть форумов, я каждый день качаю дома по диалапу полтора мега. Предлагаешь качать 5? Нафиг-нафиг такой геморой из-за одного тега. Потом кто-то придумает еще один тег, и все по новой? Ради сомнительной красоты форматирования одного слова в тексте?
Речь не о добавлении тега, а смене истемы тегов вообще. Речсь о том,чтоб сделать её расширяемой.
То есть, например, не [c], [ccode] [pascal] [perl], а [code=c], [code=pascal], [code=perl].
Добавление новога языка будет смотреться куда органичнее. Сделать списки складывемыми. Влад чего-то прелагал, но как всегда хорошие идеи канули в лету
Здравствуйте, adontz, Вы писали: A>Речь не о добавлении тега, а смене истемы тегов вообще. Речсь о том,чтоб сделать её расширяемой. A>То есть, например, не [c], [ccode] [pascal] [perl], а [code=c], [code=pascal], [code=perl]. A>Добавление новога языка будет смотреться куда органичнее. Сделать списки складывемыми. Влад чего-то прелагал, но как всегда хорошие идеи канули в лету
Я кстати это в свое время предлагал. Но в какой-то момент забыл, зачем, и не сиог обосновать Владу
Смысл в том, что при отсутствии конкретного языка форматтер мог бы рендерить просто в код (то, что сейчас делает [code]). В будущем улучшение форматтера позволит раскрашивать синтаксис в этих сообщениях. Сейчас, например, я могу постить иксэмэль только как [code], а это означает невозможность раскраски его в будущем.
При смены схемы тэгов базу надо апдейтить не трогая таймстампов. Если это невозможно, то упс. Кроме этого, старые теги заменять на новые при сабмите/превью.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Kupaev, Вы писали:
K>>Спасибо, благодетель. Выбирая небольшую часть форумов, я каждый день качаю дома по диалапу полтора мега. Предлагаешь качать 5? Нафиг-нафиг такой геморой из-за одного тега. Потом кто-то придумает еще один тег, и все по новой? Ради сомнительной красоты форматирования одного слова в тексте?
A>Речь не о добавлении тега, а смене истемы тегов вообще. Речсь о том,чтоб сделать её расширяемой. A>То есть, например, не [c], [ccode] [pascal] [perl], а [code=c], [code=pascal], [code=perl]. A>Добавление новога языка будет смотреться куда органичнее. Сделать списки складывемыми. Влад чего-то прелагал, но как всегда хорошие идеи канули в лету
Дык понял. Однако лучшее — враг хорошего. Тут вон уже база на сидюк не лезет, даже думать страшно о том, чтобы ее заново качать.
Можно иметь паралельно две системы разметки и флажок в каждом сообщении, в какой она системе. И пусть новые сообщения пишутся по-новому, а старые хранятся по-старому.
Здравствуйте, jazzer, Вы писали:
J>>да просто добавьте спановый тег типа fixed или monospace — и уже будет гораздо лугче
J>Ну что, предложение не прошло?
((
. В текстах с пропорциональным шрифтом такие вещи обычно выделяют фиксированным.
А просто добавить один (1) новый тэг нельзя? А старые не трогать.
Если нам не помогут, то мы тоже никого не пощадим.
