Всем привет!

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

Пример:

void foo();
int bar();
float baz();

В этом абзаце я пишу о функциях foo(), bar() и baz(). Хочу видеть их имена отличающимися от текста. Просто выделение жирным и/или курсивом это немножко не то . В текстах с пропорциональным шрифтом такие вещи обычно выделяют фиксированным.

Спасибо.
Tuo_Bellas.

P.S. Я, конечно, понимаю, мы не можем эмулировать TEX... А жаль...

Здравствуйте, Tuo_Bellas, Вы писали:

void foo();
int bar();
float baz();

Здравствуйте, Tuo_Bellas, Вы писали:

[/ccode]
void foo();
int bar();
float baz();
[/ccode]

Здравствуйте, Tuo_Bellas, Вы писали:

[/ccode]
void foo();
int bar();
float baz();
[/ccode]

Здравствуйте, _MarlboroMan_, Вы писали:

_MM_>[/ccode]
_MM_>void foo();
_MM_>int bar();
_MM_>float baz();
_MM_>[/ccode]

Да нет, я не этот текст хочу выделить. Тот, что в тексте. Чтобы можно было написать в тексте абзаца, скажем [/ccode]foo[/ccode], и не начиналась новая строка как сейчас:

foo

.

Спасибо.
Tuo_Bellas.

Здравствуйте, Tuo_Bellas, Вы писали:
Дело хорошее. Вот только геморройное. Дублировать всю раскраску — самоубийство, у нас в два раза вырастет количество тэгов. Просто заменить в форматтере див на спан — исковеркать большое количество сообщений. В общем, сомнения смутные терзают. Попробуем убедить кого-нибудь из рулевых потестироваться.

Здравствуйте, Sinclair, Вы писали:

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

Естественно нужен новый тэг. Не [ccode].

Можно и без раскраски. Куски кода в абзацах обычно небольшие, расскрашивать не очень много. Хотя бы просто Courier на сером фоне -- и то хорошо.

А для раскраски можно прикрутить опциональный параметр тэга с именем языка. Типа [ic] -- аналог [code], [ic lang="c"] -- аналог [ccode], [ic lang="pascal"] для паскаля и т.п. Если архитектура форматтера поддерживает.

Tuo_Bellas.

Здравствуйте, Tuo_Bellas, Вы писали:
T_B>А для раскраски можно прикрутить опциональный параметр тэга с именем языка. Типа [ic] -- аналог [code], [ic lang="c"] -- аналог [ccode], [ic lang="pascal"] для паскаля и т.п. Если архитектура форматтера поддерживает.
вот я и говорю — удвоится количество тегов.
T_B>Tuo_Bellas.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Tuo_Bellas, Вы писали:
S>Дело хорошее. Вот только геморройное. Дублировать всю раскраску — самоубийство, у нас в два раза вырастет количество тэгов. Просто заменить в форматтере див на спан — исковеркать большое количество сообщений. В общем, сомнения смутные терзают. Попробуем убедить кого-нибудь из рулевых потестироваться.

да просто добавьте спановый тег типа fixed или monospace — и уже будет гораздо лугче

You will always get what you always got
  If you always do  what you always did

Здравствуйте, 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# например). Этим тегом, повторюсь, подсвечиваться будут в основном короткие участки текста.

Tuo_Bellas.

Здравствуйте, Sinclair, Вы писали:

S>вот я и говорю — удвоится количество тегов.

С какой стати? Разве нельзя в УЖЕ существующих сообщениях просто заменить старые теги на новые? Туту конечно не простой запрос, да и вряд ли только SQL обойдётся (хотя можно поизвращатся), но надо отрабатывать 2-х процессорный сервер

Здравствуйте, adontz, Вы писали:

A>С какой стати? Разве нельзя в УЖЕ существующих сообщениях просто заменить старые теги на новые? Туту конечно не простой запрос, да и вряд ли только SQL обойдётся (хотя можно поизвращатся), но надо отрабатывать 2-х процессорный сервер

А потом все пользователи януса получать гигабайт сообщений при следующей синхронизации.

Здравствуйте, IT, Вы писали:

IT>А потом все пользователи януса получать гигабайт сообщений при следующей синхронизации.

Во-первых далеко не все сообщения содержат коды форматирования, а во-вторых этот процесс можно запросто растянуть во времени поддерживая 4-6 месяцев оба вида кодов форматирования, но разрешая вводить только новые.

Плюс такого дела — многие получат в Янус почти полную БД сообщений (а с дополнением оборванных веток ну совсем почти полную.) Смотри на вещи оптимистичнее. Если в день придётся качать не 200, а 600кб от этого некто не умрёт. И потом, кто сказал, что гиг? Сейчас 600 тыс сообщений. Если в среднем по 1кб на сообщение (янус ведь берёт именно текст, а не HTML и форматирует уже на месте), то это пол гига. А с учётом того, что далеко не всё форматированно, на самом деле мегабайт 100. Растяни это на 3 месяца, по 1мб в сутки лишний. Если ещё и по суткам растянуть (2-4 раза в сутки) то никто и не заметит ничего. Растяни на пол-года, лишних 500кб/день никто и не заметит! Более того если сделать сервис который будет с указанной скоростью (сообщений/мин) конвертировать сообщения, то нагрузка будет ну совсем равномерной.
Так что не пугай народ!

Здравствуйте, adontz, Вы писали:

A>Более того если сделать сервис который будет с указанной скоростью (сообщений/мин) конвертировать сообщения,

Чтоб за 6-8 месяцев сконвертировать всю БД нужна скорость 2.5 сообщения в минуту. Сейчас средняя скорость поступления новых сообщений 1 сообщение в минуту. Увеличение нагрузки на Янус при таком режиме будет в 3.5 раза. Веб интерфейсу будет ясное дело плевать (или нет?) Кстати что случится вс NNTP?

Предлагю открыть голосование, ИМХО дело хорошее...

Здравствуйте, adontz, Вы писали:

S>>вот я и говорю — удвоится количество тегов.

A>С какой стати? Разве нельзя в УЖЕ существующих сообщениях просто заменить старые теги на новые? Туту конечно не простой запрос, да и вряд ли только SQL обойдётся (хотя можно поизвращатся), но надо отрабатывать 2-х процессорный сервер

Нет, я точно ничего не понимаю. А просто добавить один (1) новый тэг нельзя? А старые не трогать.

Спасибо.
Tuo_Bellas.

Здравствуйте, Tuo_Bellas, Вы писали:

T_B>Нет, я точно ничего не понимаю. А просто добавить один (1) новый тэг нельзя? А старые не трогать.

Можно, но это тупиковый путь развития. Правильный путь, это тег [code], который не включает в себя автоматически переносы строк в начале и конце и поддерживает язык как параметр. То есть не [ccode], [vb], [java], а [code=c], [code=vb], [code=java]. Причём тег воспринимается не целиком, а именно как тег с параметром.

Точно так же как тег [list] давно пора сделать вкладываемым (сейчас 2 списка один в другом не делается) и параметризированным. То есть, чтобы набрав [list=3] я получил список элементы которого нумеруются с трёх. Очень удобно когда хочешь продожить список. Так же давно уже пора распознавать списки в таком виже

1)
2)
3)

а)
б)
в)

Потому что они быстрее набираются (код

для обозначения пункта был выбран крайне неудачно. Надо или шёлкать мышью, то есть отрывать руку от клавиатуры, либо переключатся в английскую раскладку и потом опять в русскую, что тоже неудобно).
Распознавать можно по запросу (как есть checkbox отключить смайлики, можно сделать checkbox — отключить распознавание списков).
При такой модернизации поддерживать старые коды просто неудобно.

Hello, adontz!

a> набрав [list=3] я получил список элементы которого нумеруются с трёх.
a> Очень удобно когда хочешь продожить список. Так же давно уже пора

Это уже давно есть. Ты попробуй [list=3], [list=a], [list=I].

Здравствуйте, der Igel, Вы писали:

DI>Это уже давно есть. Ты попробуй [list=3], [list=a], [list=I].

Да ну? А чё мочали? А вот распознавание списков
1)
2)
3)
Если сделать, то будет вообще офигительно! Ну подмай сам, набирать в русской раскладке

это ужас!

Здравствуйте, adontz, Вы писали:

T_B>>Нет, я точно ничего не понимаю. А просто добавить один (1) новый тэг нельзя? А старые не трогать.

A>Можно, но это тупиковый путь развития. Правильный путь, это тег [code], который не включает в себя автоматически переносы строк в начале и конце и поддерживает язык как параметр.
[...]

Это все, конечно хорошо, и я, конечно, за. Но это все "потом и не скоро". А мне хочется "сейчас и сразу".

Tuo_Bellas.

Здравствуйте, _MarlboroMan_, Вы писали:

на странице http://xpoint.ru/help/formatting.xhtml есть выделение "код в контексте", вот именно такого не хватает...