Comments 35
Красивый код. Если не сложно, — в данном применении какие плюсы у ТеХ- супротив wiki-разметки?
Спасибо. Особо никаких. Хотя кое-что могу назвать:
1. Чисто субъективное мнение разработчика — что именно красивее. Мы решили, что ТеХ. Вы можете решить, что вики, или бб.
2. Имхо, проще для разработчика (особо, с данной библиотекой). Не нужно для каждого тега писать парсер и придумывать отдельные правила — достаточно передать методом один объект и его название
3. Используется один, интуитивно-понятный, стандарт. \название_тега{аргумент1}{аргументN}. В вики — на каждый отдельный тег задается свой закрывающий символ и открывающий. Разработчик решил добавить покраску в цвета? Как он сделает? ~RedText/? ~^red RedText^~? Или как-то еще? В данном случае есть стандарт: \color{red}{RedText}
4. Можно передавать легко и красиво огромное количество аргументов (пример со стайлом). При этом заметьте — есть часть, которая ищет теги, а есть часть, которая размечает теги и разработчику с ТеХ-библиотекой необходима только вторая, в то время, как в вики-разметке постоянно придётся работать с обоими (для каждого тега писать свои особые правила с бл..)
Но, опять же повторюсь, скорее всего — это чисто субъективное решение. Кто-то с ума сходит по крутости вики-разметки, а кто-то — её терпеть не может.
1. Чисто субъективное мнение разработчика — что именно красивее. Мы решили, что ТеХ. Вы можете решить, что вики, или бб.
2. Имхо, проще для разработчика (особо, с данной библиотекой). Не нужно для каждого тега писать парсер и придумывать отдельные правила — достаточно передать методом один объект и его название
3. Используется один, интуитивно-понятный, стандарт. \название_тега{аргумент1}{аргументN}. В вики — на каждый отдельный тег задается свой закрывающий символ и открывающий. Разработчик решил добавить покраску в цвета? Как он сделает? ~RedText/? ~^red RedText^~? Или как-то еще? В данном случае есть стандарт: \color{red}{RedText}
4. Можно передавать легко и красиво огромное количество аргументов (пример со стайлом). При этом заметьте — есть часть, которая ищет теги, а есть часть, которая размечает теги и разработчику с ТеХ-библиотекой необходима только вторая, в то время, как в вики-разметке постоянно придётся работать с обоими (для каждого тега писать свои особые правила с бл..)
Но, опять же повторюсь, скорее всего — это чисто субъективное решение. Кто-то с ума сходит по крутости вики-разметки, а кто-то — её терпеть не может.
ну и, как я уже заметил, мы решили, что в идеологию консольного форума лучше всего впишется именно ТеХ-разметка. Это к первому пункту.
то есть плевать на удобство использования. главное — удобство реализации.
ну что за категоричность? почему если какая-то библиотека удобна программисту — она обязательно неудобна пользователю? что за привычка перевернуть слова только ради того, чтобы похаять человека?
заметьте — разработчик в конфе был только я. И еще несколько конечных пользователей, которые единогласно сошлись на мнении, что ТеХ разметка — лучше.
а что удобнее — мнение субъективное.
заметьте — разработчик в конфе был только я. И еще несколько конечных пользователей, которые единогласно сошлись на мнении, что ТеХ разметка — лучше.
а что удобнее — мнение субъективное.
достаточно посчитать сколько требуется нажатий клавиш для одного и того же…
вы б ещё xml заюзали…
вы б ещё xml заюзали…
что за стремление свести количество символов к минимуму? малое количество символов — не показатель качества. часто даже наоборот.
о каком ещё качестве ты говоришь? засеки сколько времени нужно для выделения слова, нажимая 4 клавиши, чередуя нажатие шифта и появляющиеся вследствие этого опечатки — это всё отвлекает от мысли
в следующий раз, когда будеш программировать на своём любимом языке — ни в коем случае не пиши название переменные, названия классов и методов длиннее трёх букв — ведь это столько много клавиш нужно нажимать. А еще не меняй регистр — пиши все только в нижнем, ведь надо еще чередовать нажатие шифта. А появляющиеся вследствие этого опечатки — всё это отвлекает от мысли.
а вообще — рекомендую перейти на HQ9+. В силу своей лаконичности этот язык — для тебя.
а вообще — рекомендую перейти на HQ9+. В силу своей лаконичности этот язык — для тебя.
могу посочувствовать верстальщикам. конечно, можно сделать и разделение через точку.
но дело в том, что данный плагин преследовал цели демонстрации данной библиотеки, а не использования его (плагина) в практических целях. если посмотреть его исходный код, то можно увидеть, что он достаточно сырой. Как я уже сказал — каждый гаразд написать свои плагины. Благо, это достаточно легко, а инструментарий и примеры — есть.
но дело в том, что данный плагин преследовал цели демонстрации данной библиотеки, а не использования его (плагина) в практических целях. если посмотреть его исходный код, то можно увидеть, что он достаточно сырой. Как я уже сказал — каждый гаразд написать свои плагины. Благо, это достаточно легко, а инструментарий и примеры — есть.
«реализующего ксс-подсветку, алля»
Имелось ввиду слово «а-ля»?
Имелось ввиду слово «а-ля»?
Зачем? На одном форуме HTML, на другом – Wiki, ещё на одном – BBCode. Неужели стандартный HTML настолько сложный, чтобы нельзя было пользователя приучить к нему одному?
TeX разметка — это круто.
И консольный форум — тоже, только стоит ли оно того? Сколько времени будет затрачено на создание библиотеки? Сколько пользователей (веб-программистов) будут ею пользоваться? Сколько пользователей сайтов с такой разметкой будут ею пользоваться?
А вообще, если ради красоты и чистоты, то да — красиво.: )
И консольный форум — тоже, только стоит ли оно того? Сколько времени будет затрачено на создание библиотеки? Сколько пользователей (веб-программистов) будут ею пользоваться? Сколько пользователей сайтов с такой разметкой будут ею пользоваться?
А вообще, если ради красоты и чистоты, то да — красиво.: )
> И консольный форум — тоже, только стоит ли оно того?
Посмотри на консольный форум. Почитай большинство отзывов. Такое огромное количество приятных отзывов, что, потратив на этот форум 2 месяца — я продлил жизнь на два года. Вот и вопрос — стоит ли оно того? Да и вообще подумайте сами — сколько кода вы написали, а сколько из этого кода оказалось совершенно бесполезным? И так у всех.
> Сколько времени будет затрачено на создание библиотеки?
Да данный момент — один вечер. Учитывая, что большего функционала и не нужно, то вряд-ли потратится еще больше вечера
> Сколько пользователей (веб-программистов) будут ею пользоваться?
Как минимум — один
> Сколько пользователей сайтов с такой разметкой будут ею пользоваться?
Как минимум — пользователи фрисиар.
> красиво
Спасибо)
Посмотри на консольный форум. Почитай большинство отзывов. Такое огромное количество приятных отзывов, что, потратив на этот форум 2 месяца — я продлил жизнь на два года. Вот и вопрос — стоит ли оно того? Да и вообще подумайте сами — сколько кода вы написали, а сколько из этого кода оказалось совершенно бесполезным? И так у всех.
> Сколько времени будет затрачено на создание библиотеки?
Да данный момент — один вечер. Учитывая, что большего функционала и не нужно, то вряд-ли потратится еще больше вечера
> Сколько пользователей (веб-программистов) будут ею пользоваться?
Как минимум — один
> Сколько пользователей сайтов с такой разметкой будут ею пользоваться?
Как минимум — пользователи фрисиар.
> красиво
Спасибо)
Не смог пройти мимо :)
Идея отличная — думаю что поживлюсь для само-блога, как руки дойдут написать. Консоль родная всяко удобнее мышеклацкания, и метаться туда-сюда между полем ввода и кнопочами не надо.
Посильное предожение —
PS. В primer в значениях нужно удалить пробел-отбивку перед & :(
PPS. Как хабровый парсер заставить нарисовать именно & amp; а не & ??? Он просто-таки непобедим.
Идея отличная — думаю что поживлюсь для само-блога, как руки дойдут написать. Консоль родная всяко удобнее мышеклацкания, и метаться туда-сюда между полем ввода и кнопочами не надо.
Посильное предожение —
safeHTML : function (stringIn) {
var primer = {'&':'& amp;','\'':'& #039;','\"':'& quot;','<':'& lt;','>':'& gt'};
return stringIn.replace(/[<'&">]/g, function (symb) {return primer[symb]});
}
* This source code was highlighted with Source Code Highlighter.PS. В primer в значениях нужно удалить пробел-отбивку перед & :(
PPS. Как хабровый парсер заставить нарисовать именно & amp; а не & ??? Он просто-таки непобедим.
Вы не поверите)) &
А делать надо так: &amp;amp;amp;
Спасибо)
А делать надо так: &amp;amp;amp;
Спасибо)
О!
Думаю обмен у нас с Вами равноценный.
Сурово :)
Кстати, чтоб не флудить — в liveEmails Ваше регулярное выражение потенциально имеет проблему, на мой взгляд.
Попробуйте SETI@HOME — Вы точно уверены, что именно это имелось ввиду?
Могу предложить
(?:(?:[a-z0-9][-a-z0-9]{0,61}[a-z0-9]\.)+(?:[a-z]{2}|com|org|net|gov|mil|biz|info|mobi|name|aero|jobs|museum))|local
(кто-то жаловался, что не может локальный адрес вводить)
Думаю обмен у нас с Вами равноценный.
Сурово :)
Кстати, чтоб не флудить — в liveEmails Ваше регулярное выражение потенциально имеет проблему, на мой взгляд.
Попробуйте SETI@HOME — Вы точно уверены, что именно это имелось ввиду?
Могу предложить
(?:(?:[a-z0-9][-a-z0-9]{0,61}[a-z0-9]\.)+(?:[a-z]{2}|com|org|net|gov|mil|biz|info|mobi|name|aero|jobs|museum))|local
(кто-то жаловался, что не может локальный адрес вводить)
вообще, регексп не мой, но, я думаю, там достаточно перед ([a-z]{2,6}) звёздочку — плюсиком заменить)
но за ваш вариант тоже спасибо. я так понимаю, это сразу после @ ставить надо? не особо силён в регекспах.
но за ваш вариант тоже спасибо. я так понимаю, это сразу после @ ставить надо? не особо силён в регекспах.
Да, сразу после @
Мой вариант — более канонический, что-ли.
если править Ваш, тогда
([a-z0-9][-a-z0-9]{0,61}[a-z0-9]\.)+([a-z]{2,6})
т.к стандарт вроде бы как требует не менее 2-х букв в имени
Мой вариант — более канонический, что-ли.
если править Ваш, тогда
([a-z0-9][-a-z0-9]{0,61}[a-z0-9]\.)+([a-z]{2,6})
т.к стандарт вроде бы как требует не менее 2-х букв в имени
job.i.ua/show/vacancy/262526/
Резюме з вказівкою вакансії чекаємо за адресою: hr@5.ua
Резюме з вказівкою вакансії чекаємо за адресою: hr@5.ua
Кстати, если есть понимание — могу попробовать подумать что-нибудь оптимальное и для liveUrls и url.
Только я за синтаксис вида
\url{href desc}
Проще будет написать оба обработчика так, чтобы они не пересекались.
Только я за синтаксис вида
\url{href desc}
Проще будет написать оба обработчика так, чтобы они не пересекались.
то есть синтаксис такого вида, а не \url{href}{desc}?
в данном случае это было правило, а не тег, то есть оно применяется к тексту, который не состоит в тегах. то есть само должно искать в сообщении теги.
в данном случае это было правило, а не тег, то есть оно применяется к тексту, который не состоит в тегах. то есть само должно искать в сообщении теги.
Не совсем понял
| оно применяется к тексту, который не состоит в тегах. то есть само должно искать в сообщении теги.
Я в общем-то только из практических соображений.
1. можно написать \url{href} дабы содержимое гарантировано стало выглядеть как ссылка
2. можно написать \url{href desc} дабы второе было отображеним первого
3. проще для восприятия, т.к. сущность href-desc в общем-то атомарна (на мой взгляд — desc без href — просто текст)
4. проще писать — не выпадает из канвы \teg{item}
Т.о. имеем тег \url{href desc} и правило для подсветки url, которые друг другу не мешают (правило отучаем вмешиваться в тег)
| оно применяется к тексту, который не состоит в тегах. то есть само должно искать в сообщении теги.
Я в общем-то только из практических соображений.
1. можно написать \url{href} дабы содержимое гарантировано стало выглядеть как ссылка
2. можно написать \url{href desc} дабы второе было отображеним первого
3. проще для восприятия, т.к. сущность href-desc в общем-то атомарна (на мой взгляд — desc без href — просто текст)
4. проще писать — не выпадает из канвы \teg{item}
Т.о. имеем тег \url{href desc} и правило для подсветки url, которые друг другу не мешают (правило отучаем вмешиваться в тег)
> (правило отучаем вмешиваться в тег)
Этого делать не надо. Как раз суть правил в том, что они не вмешиваются в тег, если автор тега не захотел иначе. Все, что в теге — остается таким, как передал пользователь. И уже автор тега должен определить — что надо разметить тегом, что — экранировать, что — не тронуть.
> можно написать \url{href desc}
По сути, это не сильно отличается от \url{href}{desc}. Единственное, что в начале функции надо будет сделать так:
А дальше — все действия равны. Можно даже написаь с поддержкой и первого варианта и второго.
Этого делать не надо. Как раз суть правил в том, что они не вмешиваются в тег, если автор тега не захотел иначе. Все, что в теге — остается таким, как передал пользователь. И уже автор тега должен определить — что надо разметить тегом, что — экранировать, что — не тронуть.
> можно написать \url{href desc}
По сути, это не сильно отличается от \url{href}{desc}. Единственное, что в начале функции надо будет сделать так:
// \url{href desc}
var words = args[0].split(' ');
var href = words.shift();
var desc = words.join(' ');
// \url{href}{desc}
var href = args[0];
var desc = args[1];
А дальше — все действия равны. Можно даже написаь с поддержкой и первого варианта и второго.
Вы не поверите)) &
А делать надо так: &amp;
Спасибо)
А делать надо так: &amp;
Спасибо)
Sign up to leave a comment.
TeX-like разметка на Javascript