К вопросу о форматтере
20.08.2012
|
AndrewVK |
У существующего форматтера есть целый ряд недостатков:
1) Он построен на тормозных регексах, да еще и с целой кучей проходов
2) Отсутствует программная модель разметки, как следствие сложно реализовать различные вещи типа правильного цитирования таблиц, изменений при цитировании картинок и т.п.
3) Не очень удобный для использования и избыточный синтаксис.
4) Крайне ограниченные возможности по расширению, опять же за счет того что большая часть построена на регексах
5) Отсутствие формальной и легко читаемой спецификации, что усложняет жизнь по реализации на платформах, отличных от дотнета. Ну и готовый набор тесткейсов тоже был бы не лишними.
6) У статей свой собственный, отдельный язык разметки
В связи с чем предлагаю:
1) Поднять руку тому, кому эта тема вообще интересна.
2) Обсудить оптимальный синтаксис, чтобы его и писать было удобно, и парсить не слишком сложно.
3) Если появится достаточное количество желающих — сформировать формальную спецификацию, тесткейсы и реализовать форматтер (прежде всего под .NET, ну и под другие платформы по желанию).
4) Интегрировать все это в сайт и оффлайн-клиентов.
1) Он построен на тормозных регексах, да еще и с целой кучей проходов
2) Отсутствует программная модель разметки, как следствие сложно реализовать различные вещи типа правильного цитирования таблиц, изменений при цитировании картинок и т.п.
3) Не очень удобный для использования и избыточный синтаксис.
4) Крайне ограниченные возможности по расширению, опять же за счет того что большая часть построена на регексах
5) Отсутствие формальной и легко читаемой спецификации, что усложняет жизнь по реализации на платформах, отличных от дотнета. Ну и готовый набор тесткейсов тоже был бы не лишними.
6) У статей свой собственный, отдельный язык разметки
В связи с чем предлагаю:
1) Поднять руку тому, кому эта тема вообще интересна.
2) Обсудить оптимальный синтаксис, чтобы его и писать было удобно, и парсить не слишком сложно.
3) Если появится достаточное количество желающих — сформировать формальную спецификацию, тесткейсы и реализовать форматтер (прежде всего под .NET, ну и под другие платформы по желанию).
4) Интегрировать все это в сайт и оффлайн-клиентов.
... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>
20.08.2012 223 комментария |
AVK> В связи с чем предлагаю:
AVK> 1) Поднять руку тому, кому эта тема вообще интересна.
AVK> 3) Если появится достаточное количество желающих — сформировать формальную спецификацию, тесткейсы и реализовать форматтер (прежде всего под .NET, ну и под другие платформы по желанию).
Я на данный момент готов собрать максимальное количестов тэгов разметки, которые так или иначе использовались (то, что форматтер их не поддерживает, часто не мешает людям использовать). Это позволит посмотреть с чем вообще имеем дело и сможем ли сохранить обратную совместимость, возможно чем-то пожертвовать и т.д. Т.е. оценить "масштаб бедствия".
А так же писать/поддерживать тесты, если формат входящих и сравниваемых данных будет независим от .NET (чтобы иметь возможность проверять тесты локально).
AB>Я на данный момент готов собрать максимальное количестов тэгов разметки, которые так или иначе использовались (то, что форматтер их не поддерживает, часто не мешает людям использовать)
Это ты вообще о чем?
AB>. Это позволит посмотреть с чем вообще имеем дело и сможем ли сохранить обратную совместимость, возможно чем-то пожертвовать и т.д. Т.е. оценить "масштаб бедствия".
Обратная совместимость вовсе не обязательна. Мне вообще идея тегов совсем не нравится, много писанины и переключений раскладки. Я скорее к чему то навроде markdown предрасположен. А для старых сообщений можно либо конвертер сделать, либо просто ввести флажок в БД сервера — тип форматтера.
AB>А так же писать/поддерживать тесты, если формат входящих и сравниваемых данных будет независим от .NET (чтобы иметь возможность проверять тесты локально).
Формат, разумеется, будет независим. Именно в этом и смысл. Да и какой там формат? Размеченный текст на входе, html в качестве образца результата.
AVK> AB>Я на данный момент готов собрать максимальное количестов тэгов разметки, которые так или иначе использовались (то, что форматтер их не поддерживает, часто не мешает людям использовать)
AVK> Это ты вообще о чем?
Я просто думал, что предполагается оставить совместимость с уже имеющейся разметкой.
AVK> Обратная совместимость вовсе не обязательна. Мне вообще идея тегов совсем не нравится, много писанины и переключений раскладки. Я скорее к чему то навроде markdown предрасположен. А для старых сообщений можно либо конвертер сделать, либо просто ввести флажок в БД сервера — тип форматтера.
На сколько я понимаю, синтаксис markdown покрывает практически все текущие потребности и для него есть уже готовые парсеры на разных языках (т.е. изобретать ничего особо не придется, а даже наоборот, возможно, урезать).
Основная используемая разметка на форумах:
* Списки (~1%)
* Изображения (~2%)
* Цитаты (~6%) — в markdown отсутствует явный аналог
* Код (~15%) — потребует небольшой доработки для разделения по языкам (типа как на github)
* Ссылки (~18%)
* Таглайн (22%) — с удовольствием бы пожертвовал за ненадобностью
* Выделение текста — B/U/I/S (~25%)
Тэги email и msdn легко заменяются ссылками, остаются тэг moderator и таблицы.
Оставлю эту статистику до утра — с хорошей мыслью надо переспать.
AB>На сколько я понимаю, синтаксис markdown покрывает практически все текущие потребности
И десятой части не покрывает.
AB> и для него есть уже готовые парсеры на разных языках (т.е. изобретать ничего особо не придется, а даже наоборот, возможно, урезать).
Боюсь, все таки придется.
AB>* Цитаты (~6%) — в markdown отсутствует явный аналог
Цитаты там есть, почти такие же как сейчас, только без указания автора в префиксе. Или ты про блочную цитату?
AB>* Код (~15%) — потребует небольшой доработки для разделения по языкам (типа как на github)
AB>* Ссылки (~18%)
AB>* Таглайн (22%) — с удовольствием бы пожертвовал за ненадобностью
AB>* Выделение текста — B/U/I/S (~25%)
AB>Тэги email и msdn легко заменяются ссылками, остаются тэг moderator и таблицы.
https://bitbucket.org/andrewvk/rsdn.format/wiki/Specification — там список категорий
AVK>Обратная совместимость вовсе не обязательна. Мне вообще идея тегов совсем не нравится, много писанины и переключений раскладки. Я скорее к чему то навроде markdown предрасположен. А для старых сообщений можно либо конвертер сделать, либо просто ввести флажок в БД сервера — тип форматтера.
Для олдфагов оставьте BBCode, пожалуйста
AVK>У существующего форматтера есть целый ряд недостатков:
AVK>1) Он построен на тормозных регексах, да еще и с целой кучей проходов
AVK>2) Отсутствует программная модель разметки, как следствие сложно реализовать различные вещи типа правильного цитирования таблиц, изменений при цитировании картинок и т.п.
AVK>3) Не очень удобный для использования и избыточный синтаксис.
AVK>4) Крайне ограниченные возможности по расширению, опять же за счет того что большая часть построена на регексах
AVK>5) Отсутствие формальной и легко читаемой спецификации, что усложняет жизнь по реализации на платформах, отличных от дотнета. Ну и готовый набор тесткейсов тоже был бы не лишними.
AVK>6) У статей свой собственный, отдельный язык разметки
AVK>В связи с чем предлагаю:
AVK>1) Поднять руку тому, кому эта тема вообще интересна.
AVK>2) Обсудить оптимальный синтаксис, чтобы его и писать было удобно, и парсить не слишком сложно.
AVK>3) Если появится достаточное количество желающих — сформировать формальную спецификацию, тесткейсы и реализовать форматтер (прежде всего под .NET, ну и под другие платформы по желанию).
AVK>4) Интегрировать все это в сайт и оффлайн-клиентов.
У меня есть некоторое свободное время до конца года, из нужного тебе опыта — создания компилятора из теха в метайфайл для врачей и разметки различных виндовских логов по группам (ну это далеко), так что если есть потребность в руках — свисти.
D>У меня есть некоторое свободное время до конца года, из нужного тебе опыта — создания компилятора из теха в метайфайл для врачей и разметки различных виндовских логов по группам (ну это далеко), так что если есть потребность в руках — свисти.
Пока есть потребность придумать удобный и функциональный синтаксис, покрывающий все возможности форматтера текущего. Как я уже писал — за основу можно взять markdown.
Проект на bitbucket я открою.
AVK>Здравствуйте, denisko, Вы писали:
D>>У меня есть некоторое свободное время до конца года, из нужного тебе опыта — создания компилятора из теха в метайфайл для врачей и разметки различных виндовских логов по группам (ну это далеко), так что если есть потребность в руках — свисти.
AVK>Пока есть потребность придумать удобный и функциональный синтаксис, покрывающий все возможности форматтера текущего.
Ок, понял. Прими тогда в качестве реквеста поддержку отображения формул (если есть возможность), потому что иногда надо что -то формулой показать, а на словах выходит криво.
d> Ок, понял. Прими тогда в качестве реквеста поддержку отображения формул (если есть возможность), потому что иногда надо что -то формулой показать, а на словах выходит криво.
С формулами, к счастью, все более-менее просто — достаточно тэга img:
\underbrace{a+\overbrace{b+\cdots+y}^{24}+z}_{26}
\sqrt{1+\sqrt{1+\sqrt{1+\sqrt{1+\sqrt{1+\sqrt{1+\sqrt{1+x}}}}}}}
AVK>Здравствуйте, denisko, Вы писали:
D>>У меня есть некоторое свободное время до конца года, из нужного тебе опыта — создания компилятора из теха в метайфайл для врачей и разметки различных виндовских логов по группам (ну это далеко), так что если есть потребность в руках — свисти.
AVK>Пока есть потребность придумать удобный и функциональный синтаксис, покрывающий все возможности форматтера текущего. Как я уже писал — за основу можно взять markdown.
В маркдауне есть одна большая проблема — он контекстно зависим. То ест, например, внутри блочных элементов по канону маркдаун не парсится: http://daringfireball.net/projects/markdown/syntax
Плюс есть свои заморочки типа inline html позволяется, но несбалансированные скобки экранируются (см. секцию inline html).
То есть, все сильно зависит от того, насколько сильно вы будете основывать именно на маркдауне
M>В маркдауне есть одна большая проблема — он контекстно зависим. То ест, например, внутри блочных элементов по канону маркдаун не парсится: http://daringfireball.net/projects/markdown/syntax
Поэтому — взять за основу.
M>Плюс есть свои заморочки типа inline html
Выкинуть.
M>То есть, все сильно зависит от того, насколько сильно вы будете основывать именно на маркдауне
В меру разумного.
AVK>Репозиторий и вики — https://bitbucket.org/andrewvk/rsdn.format
Краткая документация по вики:
https://confluence.atlassian.com/display/BITBUCKET/Using+a+bitbucket+Wiki
+ возможно http://www.wikicreole.org/wiki/Creole1.0
Из первых косяков.
Битбакетовская вика не полностью поддерживает русский язык в заголовках, поэтому построить оглавление с использованием встроенных средств не получится (<<toc 3>> — оглавление вплоть до третьего уровня заголовков). Само оглавление построится, но переходить по ссылкам будет невозможно.
Почему это происходит.
Код
Даёт такой html
Насколько удалось понять, встроенных средств для работы с anchor-ами и линками на них тоже нет. Увы.
SO>Из первых косяков.
SO>Битбакетовская вика не полностью поддерживает русский язык в заголовках, поэтому построить оглавление с использованием встроенных средств не получится (<<toc 3>> — оглавление вплоть до третьего уровня заголовков). Само оглавление построится, но переходить по ссылкам будет невозможно.
Это проблема в их реализации и только — я давно как-то им писал об этом, но видимо так и не починили, всё таки буржуям этим наш русский нафиг не упал.
PS: А вот Nemerle в свойства репы — добавили быстро и без проблем (тем более, что N и так уже подсвечивался пигментами).
F> Это проблема в их реализации и только — я давно как-то им писал об этом, но видимо так и не починили, всё таки буржуям этим наш русский нафиг не упал.
Так с этим никто и не спорит — пойнт в том, что нам теперь с этим косяком жить и он совершенно не очевиден в начале работы. Плюс, косвенное свидетельство сырости битбакетовской вики — надо быть готовым и к другим сюрпризам.
AVK>5) Отсутствие формальной и легко читаемой спецификации, что усложняет жизнь по реализации на платформах, отличных от дотнета. Ну и готовый набор тесткейсов тоже был бы не лишними.
AVK>6) У статей свой собственный, отдельный язык разметки
http://www.redmine.org/projects/redmine/wiki/RedmineTextFormatting
http://trac.edgewall.org/wiki/0.12/WikiFormatting
http://en.wikipedia.org/wiki/Lightweight_markup_language
Накидаю идей. Мой выбор тегов продиктов
1) удобством употребления тегов форматиования в текстах на языках программирования. Последовательности символов должны быть редки или невозможны для популярных языков.
1) удобством употребления тегов форматиования в текстах на языках. Последовательности символов должны быть редки или невозможны для популярных языков, удобны при надо в русской раскладке.
2) удобстовм набора
3) припродной недекватностью
Пока что придумалось такое, но я вижу много разных проблем и надо думать ещё.
$ — условное обозначение начала строки. Символ после $ — первый в строке
Cписки
.1 пункт
.1.1 под-пункт
.4 пункт с принудительным номером
.* пункт
.*.* под-пункт
.* пункт
Ссылки
\\http://www.rsdn.ru/\\
\\msdn:GetProcAddress\\
\\книга про числа\\isbn:123-456-789\\
\\крутой сайт\\http:/www.rsdn.ru/\\
Исходный код
=====csharppublic static class Program
{
public static void Main(string[] args)
{
public const string HtmlTemplate =@"
=====html
<html><body></body></html>
=====
";
}
}
====
DR>А почему бы не взять готовый форматтер, типа Sundown который используют на Гитхабе? У него есть байндинги для .NET.
"GitHub Flavored Markdown" — это он?
http://github.github.com/github-flavored-markdown/
Интересует описание языка разметки.
SO>"GitHub Flavored Markdown" — это он?
SO>http://github.github.com/github-flavored-markdown/
SO>Интересует описание языка разметки.
Здесь есть: http://daringfireball.net/projects/markdown/syntax
SO>>http://github.github.com/github-flavored-markdown/
DR>Здесь есть: http://daringfireball.net/projects/markdown/syntax
На странице с верхней ссылки, в самом начале, тоже идёт линк на http://daringfireball.net/projects/markdown/syntax (Markdown Syntax Guide at Daring Fireball) + далее "Differences from traditional Markdown" (я так понимаю, там перечисляются гитхабовские расширения).
Т.е. для знакомства с языком можно использовать обе ссылки.
DR>А почему бы не взять готовый форматтер, типа Sundown который используют на Гитхабе? У него есть байндинги для .NET.
Я не уверен, что он хорошо подойдет под потребности рсдн.
AVK>Здравствуйте, Don Reba, Вы писали:
DR>>А почему бы не взять готовый форматтер, типа Sundown который используют на Гитхабе? У него есть байндинги для .NET.
AVK>Я не уверен, что он хорошо подойдет под потребности рсдн.
А какие у него потребности? Ты хочешь чтобы новый форматтер использовался для форума или для статей тоже?
Если для форума, то я согласен с adontz надо выбрать наиболее эргономичные комбинации для форматирования сообщений и разработать не гемморойный механизм подсветки кода.
Если для сайта тоже, то я бы рекоммендовал что-то ТЕХоподобное, поскольку множества народа который пишет статьи [ на рсдн] и множества народа, который владеет техом сильно пересекается. Тех удобен тем, что можно задать под себя окружение и область действия команд, что для форума оверкилл и вредно.
AVK>>Я не уверен, что он хорошо подойдет под потребности рсдн.
D>А какие у него потребности?
Покрытие всего существующего функционала как минимум. Доступ к модели разметки для допфункций типа цитирования (у большинства готовых форматтеров такого нет, там просто на входе разметка, на выходе html).
D> Ты хочешь чтобы новый форматтер использовался для форума или для статей тоже?
Да.
D>Если для форума, то я согласен с adontz надо выбрать наиболее эргономичные комбинации для форматирования сообщений и разработать не гемморойный механизм подсветки кода.
И я тоже с этим согласен.
D>Если для сайта тоже, то я бы рекоммендовал что-то ТЕХоподобное
Т.е. опять два разных формата да еще и рендерер теха в html?
AVK>Здравствуйте, dеnisko, Вы писали:
AVK>>>Я не уверен, что он хорошо подойдет под потребности рсдн.
D>>А какие у него потребности?
AVK>Покрытие всего существующего функционала как минимум. Доступ к модели разметки для допфункций типа цитирования (у большинства готовых форматтеров такого нет, там просто на входе разметка, на выходе html).
Ну надо начать тогда с того, чтобы собрать требования, причем расширенные, и фичреквесты. Может быть тебе следовало бы написать спеку существующего функционала (как сайта, так и форума), чтобы все знали что есть, чего нет.
D>>Если для сайта тоже, то я бы рекоммендовал что-то ТЕХоподобное
AVK>Т.е. опять два разных формата да еще и рендерер теха в html?
РСДН еще и бумажный журнал, который так или иначе нужно верстать, проще всего это сделать в техе. Можно сблизить поелику возможно, т.е. сделать близкий по духу к ТЕХ ML, а из него сделать конвертер в настояющий ТЕХ для бумаги и в HTML для сайта.
D>Ну надо начать тогда с того, чтобы собрать требования, причем расширенные, и фичреквесты.
Я не против. Минимум в стартовом сообщении я указал.
D> Может быть тебе следовало бы написать спеку существующего функционала (как сайта, так и форума), чтобы все знали что есть, чего нет.
ИМХО, полная спека — бессмысленно потраченное время. А краткое перечисление возможностей есть в https://bitbucket.org/andrewvk/rsdn.format/wiki/Specification в виде заголовков. Там не указаны только специальные теги типа tagline или moderator. Формально полный список смайлов и тегов (кроме таглайна) такой: https://bitbucket.org/andrewvk/janus/src/8b7f2d2e7f52/Rsdn/Janus.Rsdn-Model/RsdnSyntaxInfo.cs
Если есть вопросы по семантике какого то тега — спрашивай.
AVK>>Т.е. опять два разных формата да еще и рендерер теха в html?
D>РСДН еще и бумажный журнал
Там все равно тех не годится, там нужен ворд.
D>, который так или иначе нужно верстать, проще всего это сделать в техе.
Это много раз обсуждалось. Ответ редакторов неизменен — тех не нужен.
AVK>ИМХО, полная спека — бессмысленно потраченное время. А краткое перечисление возможностей есть в https://bitbucket.org/andrewvk/rsdn.format/wiki/Specification в виде заголовков.
Это мало пригодно для дополнительного форматирования исходного кода. То есть var x = 1/2; станет началом курсивного блока. Будет путаница.
Соглашусь с batu (я мало понял его мысль, но что потом не обиделся, что украли) об интересности, ассиметричного форматирования.
То есть например :* начинает жирный текст, :/ начинает курсив, :: очищает форматирование.
:*жирный и :/курсив:: просто текст -> жирный и курсив просто текст
AVK>1) Поднять руку тому, кому эта тема вообще интересна.
+
AVK>2) Обсудить оптимальный синтаксис, чтобы его и писать было удобно, и парсить не слишком сложно.
В качестве базы весьма симпатичен Tiddlywiki: списки, нумерованные списки, ссылки, цитаты, заголовки, таблицы (http://www.scribd.com/doc/2189287/Tiddlywiki-Formatting-Guide).
Впрочем, у большинства вики-движков синтаксис аналогичен или близок.
Сложный вопрос — форматирование цитат при ответе.
AVK>3) Если появится достаточное количество желающих — сформировать формальную спецификацию, тесткейсы и реализовать форматтер (прежде всего под .NET, ну и под другие платформы по желанию).
Спецификацию — можно попробовать.
Тесткейсы — возможно (если порог входа не очень крутой).
Форматтер — точно нет.
AVK>У существующего форматтера есть целый ряд недостатков:
Самый большой недостаток в отсутсвии четкой иерархии и независмости, и потому он не исправимый..
Поясню свою мысль..
Допустим надо определить (изменить) шрифт или еще какой-то параметр. Для реализации такой задачи применяется тег или команда или инструкция. Ну, так как мы привыкли в программировании. Область действия этой инструкции не задается никак. Считается что она действует вплоть до следующей команды изменяющей или отменяющей значение этого параметра. Отсюда программа, которая обеспечивает выполнение, отмену или изменение этого параметра должна не только выполнять действия с учетом значения этого параметра, но и хранить его до тех пор пока не поступит новая инструкция по изменению этого параметра... Т.е. изменяться. Понятное дело что такая программа должна заведомо знать все возможные инструкции, параметры и варианты взаимодействия. Таким образом программа реализующая инструкции должна быть достаточно сложной (апологеты фунционального языка понимают о чем речь) и являться по сути средой для тех же инструкций.
Хороший язык должен обеспечивать вложенность каждого тега (или инструкции) и обеспечивать собой среду для всех инструкций находящихся внутри нее (или его если это тег).
Здесь нас подстерегает другая проблема. Если данная инструкция обеспечивает среду (т.е. параметры) для вложенных в нее инструкций, то мы не сможем отттранслировать (не говоря уже о том что бы выполнить) данную инструкцию потому как данная инструкция заканчивается после всех инструкций находящихся внутри ее, а потому и трансляция и выполнение тоже не возможны. Получается некая неразрешимая проблема. Что б задать параметры для выполнения вложенных инструкций нужно выполнить эту инструкцию, а выполнить ее не можем потому что она еще не закончилась. Но эту проблема таки можно решать.. Если такой подход интересует, то можем продолжить с интересующимися. А если высказался не в тему, то извините.
Как обычно — куча текста и ни одной понятной и полезной мысли.
Топик создан для решения вполне конкретной проблемы, а растекаться мысилию по древу иди в философию.
http://www.wikimatrix.org/syntax.php?i=115
Сравнение наиболее часто используемых:
http://www.wikicreole.org/wiki/HeadingsReasoning
Это:
Какие будут предложения по выбору синтаксиса?
SO>Какие будут предложения по выбору синтаксиса?
Мне более симпатичен вариант с восклицательными знаками.
SO>Мне более симпатичен вариант с восклицательными знаками.
Восклицательные знаки, имхо, коррелируют с каким то аварийным сообщением. В текущем виде я эту комбинацию оставил под модераторские и системные сообщения, по семантике вроде бы больше подходит.
AVK>Восклицательные знаки, имхо, коррелируют с каким то аварийным сообщением. В текущем виде я эту комбинацию оставил под модераторские и системные сообщения, по семантике вроде бы больше подходит.
Без возражений.
Мне лично нравятся creole-like, т.е. знаки равно в начале строки.
Во-первых, это напрямую связывается с h1/h2/../h6 (логически).
Во-вторых мой мозг испорчен креолом.
Ну и в третьих — судя по твоей диаграмме — это выбор большинства.
F>Мне лично нравятся creole-like, т.е. знаки равно в начале строки.
F>Во-первых, это напрямую связывается с h1/h2/../h6 (логически).
F>Во-вторых мой мозг испорчен креолом.
F>Ну и в третьих — судя по твоей диаграмме — это выбор большинства.
Вариант с восклицательными знаками не так уж плох. А вот ====== неправильное количество знаков до и после ===== может сильно раздражать.
A>Вариант с восклицательными знаками не так уж плох. А вот ====== неправильное количество знаков до и после ===== может сильно раздражать.
Но в креоли не требуется равное количество знаков, их в конце можно не писать вообще. Т.е. вполне можно сделать, так, что бы последние знаки не игнорировать, а использовать как текст — тогда не будет "несуразицы".
А восклицательные знаки — я согласен, ничем не хуже. Я ж и написал, что лично я привык к =, и мне они нравятся. Но имхо совершенно не принципиально. Тут нужно решить, и лучше решить так, что бы было либо то, либо другое, а не так как получилось в креоли с концевыми равно, которые существуют видимо больше для совместимости с другими, имхо.
A>Вариант с восклицательными знаками не так уж плох. А вот ====== неправильное количество знаков до и после ===== может сильно раздражать.
Уровни больше 3 все равно редко используются. А 1-4 уровни очень хорошо различимы.
AVK>Здравствуйте, adontz, Вы писали:
A>>Вариант с восклицательными знаками не так уж плох. А вот ====== неправильное количество знаков до и после ===== может сильно раздражать.
AVK>Уровни больше 3 все равно редко используются. А 1-4 уровни очень хорошо различимы.
Тогда может быть сделать заголовки \section -> \subsection -> \subsectionN , где N -- показатель глубины вложенности секции должен быть от 2 до бесконечности
Вообще мне хочется, чтобы была возможность включить определенное форматирование типа \begin{italic} \end{italic} для большой группы текста.
Также надо продумать о форматировании кода, т.е. либо жестко забиваем кывтовское форматирование кода, либо позволяем включать свое т.е.
[code]
\setoffset{tabs}
\setoffset{spaces}
\setbraces{java}
пошел код
[\code]
D>Тогда может быть сделать заголовки \section -> \subsection -> \subsectionN , где N -- показатель глубины вложенности секции должен быть от 2 до бесконечности
Аргументы против синтаксиса :
* Не используется ни в одной вики http://www.wikimatrix.org/syntax.php?i=115 (да и на форумах, предполагаю, может применяться нечасто).
* Достаточно громоздок по сравнению с #Заголовок первого уровня, ##Заголовок второго уровня
D>Вообще мне хочется, чтобы была возможность включить определенное форматирование типа \begin{italic} \end{italic} для большой группы текста.
И всё форматируется наклонным шрифтом. Возможно, до конца абзаца.
D>Также надо продумать о форматировании кода, т.е. либо жестко забиваем кывтовское форматирование кода, либо позволяем включать свое т.е.
D>[code]
D>\setoffset{tabs}
D>\setoffset{spaces}
D>\setbraces{java}
D>пошел код
D>[\code]
А можешь прокомментировать что будут делать в данном случае setoffset{tabs}, setoffset{spaces}? Преобразовывать существующие в блоке кода отступы?
SO>Здравствуйте, dеnisko, Вы писали:
D>>Тогда может быть сделать заголовки \section -> \subsection -> \subsectionN , где N -- показатель глубины вложенности секции должен быть от 2 до бесконечности
SO>Аргументы против синтаксиса :
SO>* Не используется ни в одной вики http://www.wikimatrix.org/syntax.php?i=115 (да и на форумах, предполагаю, может применяться нечасто).
SO>* Достаточно громоздок по сравнению с #Заголовок первого уровня, ##Заголовок второго уровня
Зато читать легче, в #,##,## путаешься постоянно
например
против
имхо, во втором при редактировании заголовок найти проще.
D>>Вообще мне хочется, чтобы была возможность включить определенное форматирование типа \begin{italic} \end{italic} для большой группы текста.
SO>
SO>И всё форматируется наклонным шрифтом. Возможно, до конца абзаца.
// может использоваться еще где-то в тексте, а \\ забили для ссылок, будет путаница + ориентироваться по крупным конструкциям проще без предпросмотра. Мое имхо, лучшая логика для текста с разметкой -- для мелких блоков используется мелкие и максимально эргономичные конструкции типа //курсив// для крупных
\begin{italic}
абзац
\end{italic}. Причина -- проще ориентироваться.
D>>Также надо продумать о форматировании кода, т.е. либо жестко забиваем кывтовское форматирование кода, либо позволяем включать свое т.е.
D>>[code]
D>>\setoffset{tabs}
D>>\setoffset{spaces}
D>>\setbraces{java}
D>>пошел код
D>>[\code]
SO>А можешь прокомментировать что будут делать в данном случае setoffset{tabs}, setoffset{spaces}? Преобразовывать существующие в блоке кода отступы?
для подогнать отступы под твое видение мира, setoffset{tabs} -- записать табами, setoffset{spaces} -- пробелами, setoffset{spaces = 3} -- все отступы пробелами, таб /автоотступ заменяется на 3 пробела.
D>Тогда может быть сделать заголовки \section -> \subsection -> \subsectionN , где N -- показатель глубины вложенности секции должен быть от 2 до бесконечности
Я понимаю твою любовь к теху, но проблема та же, что и у h1 — прохо различимы уровни, нужно раскрадку переключать, да еще и писанины много да конфликтов куча.
D>Вообще мне хочется, чтобы была возможность включить определенное форматирование типа \begin{italic} \end{italic} для большой группы текста.
Можно добавить блочные аналоги для существующих стилей — типа *** и /// скобок.
D>Также надо продумать о форматировании кода, т.е. либо жестко забиваем кывтовское форматирование кода, либо позволяем включать свое т.е.
Я пока склоняюсь к тому, чтобы разрешить только выделение болдом внутри кода.
AVK>Здравствуйте, dеnisko, Вы писали:
D>>Тогда может быть сделать заголовки \section -> \subsection -> \subsectionN , где N -- показатель глубины вложенности секции должен быть от 2 до бесконечности
AVK>Я понимаю твою любовь к теху, но проблема та же, что и у h1 — прохо различимы уровни, нужно раскрадку переключать, да еще и писанины много да конфликтов куча.
Насчет раскладки согласен, насчет различимости только с 2 и выше уровней. Насчет писанины зависит от того, как ты хочешь реализовывать. Если ползать чем-то типа saxа по тексту, ловить ключевики, искать совпадаюшие с ними конечные ключевики и потом плеваться блоками между этими ключевиками на обработку форматтеру, то \section это просто еще один ключевик, для которого задаются правила. Если по другому, то да может превратиться в геморрой.
AVK>Можно добавить блочные аналоги для существующих стилей — типа *** и /// скобок.
Ну тогда надо добавить, ибо удобно.
D>>Также надо продумать о форматировании кода, т.е. либо жестко забиваем кывтовское форматирование кода, либо позволяем включать свое т.е.
AVK>Я пока склоняюсь к тому, чтобы разрешить только выделение болдом внутри кода.
А к переформатированию как относишься? Иногда нужно, ибо читать совсем не форматированный или дико-форматированный код тяжело.
SO>Какие будут предложения по выбору синтаксиса?
Я в https://bitbucket.org/andrewvk/rsdn.format/wiki/Specification указал вариант со знаками =. Как оказалось, он же наиболее часто используемый. !! мне не нравится, h2. плохо видно в неформатированном тексте — сливается с ним и уровни неразличимы. = в конце в большинстве вик опционально и просто игнорируется. Мне кажется, смысла в таком нет, и так все хорошо видно.
AVK>Очень предварительная версия синтаксиса — https://bitbucket.org/andrewvk/rsdn.format/wiki/Specification , нет только таблиц пока.
Я тут подумал. Не весь код, ведь, оформляеться, как код. То есть как бы текст
"Если поле _first класса LinkedList равно полю _last, то список считается пустым"
не превратился в
"Если поле first класса LinkedList равно полю last, то список считается пустым"
С подчерками и другими значками надо осторожнее. Я потому и хотел их удваивать. Иначе придётся кучу исключений продумать и не факт что будет всегда нормально работать.
A> Я потому и хотел их удваивать. Иначе придётся кучу исключений продумать и не факт что будет всегда нормально работать.
А с удвоением выглядит хуже. Так что я ХЗ.
AVK>Очень предварительная версия синтаксиса — https://bitbucket.org/andrewvk/rsdn.format/wiki/Specification , нет только таблиц пока. На примеры html внимания не обращать.
Комментарии.
1. Жирный, курсив, подчёркивание, зачёркивание, верхний и нижний индексы — только с помощью двойных символов **bold**, //italic// и т.д. Аргументация — одиночные символы время от времени встречаются в простом тексте и неочевидный результат форматирования обязательно будет сбивать с толку новичков. По выбранным символам комментариев нет.
2. Заголовки. ИМХО, более интуитивно простыми будут восклицательные знаки, но против знаков равенства особых возражений нет. Отсутствие знаков с правой стороны от заголовка — большой плюс.
3. Списки. Важно добавить уровни
4. Ссылки
[[a link]]
[[a link|with title]]
Изображения сделать на основе ссылок (конкретное предложение будет чуть позже).
5. Код и цитирование
Какие альтернативы есть? Тут ошибиться в выборе нельзя, иначе потом будет мучительно больно.
SO>#
А как же препроцессор языка C?
SO>>#
M>А как же препроцессор языка C?
Будет располагаться в блоке кода, на который распространяются совсем другие правила форматирования.
Список
Блок кода на C/C++
SO>1. Жирный, курсив, подчёркивание, зачёркивание, верхний и нижний индексы — только с помощью двойных символов **bold**, //italic// и т.д. Аргументация — одиночные символы время от времени встречаются в простом тексте и неочевидный результат форматирования обязательно будет сбивать с толку новичков. По выбранным символам комментариев нет.
Против. Нужно, чтобы одиночные символы в простом тексте не считались за маркеры форматирования.
Неформально, чтобы понять, может ли пара символов интерпретироваться как маркеры форматирования, нужно попробовать заменить их на скобки. Если при этом получается недопустимая по правилам типографики последовательность — значит, не может.
Примеры:
Случаи, когда требуется выделить часть слова, считаю редкими и предлагаю обсудить отдельно на примерах. Сразу парочку контрпримеров, где выделение части слова не нужно:
* ударение: неправильно — напис/а/л; правильно — написа́л (и да, давайте сменим шрифт с Verdan’ы, пока не все ещё проапгрейдились)
* исправление орфографии: неправильно — «не к/а/рова, а к/о/рова», правильно — проигнорировать или написать в личку
SO>2. Заголовки. ИМХО, более интуитивно простыми будут восклицательные знаки, но против знаков равенства особых возражений нет. Отсутствие знаков с правой стороны от заголовка — большой плюс.
Я за == с игнорированием знаков справа.
SO>3. Списки. Важно добавить уровни
+1.
SO>4. Ссылки
SO>[[a link]]
SO>[[a link|with title]]
SO>Изображения сделать на основе ссылок (конкретное предложение будет чуть позже).
+1.
SO>5. Код и цитирование
SO>Какие альтернативы есть? Тут ошибиться в выборе нельзя, иначе потом будет мучительно больно.
Trac: (shebang-конвенция активно не нравится!)
bbcode-style: (да, считаю для фрагментов кода допустимым)
старый Confluence:
новый Confluence: (слишком многословно)
Bruce Eckel–style: (Thinking in C++/Java)
Неудачные варианты: классический Markdown, классическая Ward’s Wiki (индентация).
А кроме того, я полагаю, что можно перенести синтаксическую раскраску на клиента: в HTML отдавать <pre><code class="language-php">, а клиентский скрипт пусть расставляет все span’ы.
Цитирование вещь неочевидная. Fido-style префиксы (FML>) хороши для гейтования в NNTP, но желателен алгоритм reflow при перецитировании. В идеале, должно быть можно взять сообщение, применить на него алгоритм цитирования (приклеивающий префикс FML> к оригинальным строкам и увеличивающий уровень вложенности в цитированных), затем вставить свои новые строки (возможно, с разметкой) в любом месте, и получившееся должно быть валидным сообщением. В частности, должен работать пример:
Ожидаемое поведение:
C>А кроме того, я полагаю, что можно перенести синтаксическую раскраску на клиента: в HTML отдавать <pre><code class="language-php">, а клиентский скрипт пусть расставляет все span’ы.
Мысль, конечно, интересная, особенно интересная тем, что можно что нибудь готовое использовать, типа highlight.js. Но требования к клиенту, если мы раскраску хотим, существенно повышаются. И добавление нового языка будет несколько проблематично (nemerle, скажем, точно готового нет, а ведь захотят некоторые). С другой стороны, всегда ведь можно раскраску сразу в генераторе html прикрутить позже.
SO>1. Жирный, курсив, подчёркивание, зачёркивание, верхний и нижний индексы — только с помощью двойных символов **bold**, //italic// и т.д. Аргументация — одиночные символы время от времени встречаются в простом тексте и неочевидный результат форматирования обязательно будет сбивать с толку новичков. По выбранным символам комментариев нет.
Видимо да, придется.
SO>3. Списки. Важно добавить уровни
Да, тут просто я не уверен на 100% пока в синтаксисе.
SO>4. Ссылки
SO>[[a link]]
SO>[[a link|with title]]
А чем предложенное не устраивает?
SO>Изображения сделать на основе ссылок (конкретное предложение будет чуть позже).
Вроде бы так и есть сейчас.
SO>5. Код и цитирование
SO>Какие альтернативы есть? Тут ошибиться в выборе нельзя, иначе потом будет мучительно больно.
Альтернатив не очень много. Помимо двойных и тройных {} я встречал 4-5 символов =, но это писать больше. В маркдауне используется grave accent, но у некоторых этот символ используется для переключения раскладки. Еще есть выделение кода 4 пробелами с начала строки, тут я вообще затрудняюсь оценить, насколько оно удобно. Ббшный [code][/code] тоже применяется, но он очень многословен. Остальные варианты довольно экзотичны, но если кто знает какой интересный вариант — можно обсудить.
SO>>4. Ссылки
SO>>[[a link]]
SO>>[[a link|with title]]
AVK>А чем предложенное не устраивает?
О квадратных скобках.
http://www.wikicreole.org/wiki/LinksReasoning
Классическое решение для вики — ссылка в одинарных или двойных квадратных скобках.
О двойных квадратных скобках.
С учётом того, что на рсдн в обычном тексте вполне могут мелькать одинарные квадратные скобки (индексы в контейнерах, отрезки, диапазоны), то имеет смысл сделать двойные скобки. Двойные квадратные скобки тоже могут встречаться в обычном тексте, но предполагаю, существенно реже.
Оформление ссылок (внутренние и внешние):
http://www.wikimatrix.org/syntax.php?i=138
http://www.wikimatrix.org/syntax.php?i=139
SO>Классическое решение для вики — ссылка в одинарных или двойных квадратных скобках.
Есть одна проблема — сиволов [|] нет в русской раскладке. Но чем их заменить у меня идей нет. Двойными или тройными обычными скобками?
AVK>Здравствуйте, ShaggyOwl, Вы писали:
SO>>Классическое решение для вики — ссылка в одинарных или двойных квадратных скобках.
AVK>Есть одна проблема — сиволов [|] нет в русской раскладке. Но чем их заменить у меня идей нет. Двойными или тройными обычными скобками?
Может, кавычками (если ты их не забил уже), а цитата частный случай ссылки?
AVK>>Есть одна проблема — сиволов [|] нет в русской раскладке. Но чем их заменить у меня идей нет. Двойными или тройными обычными скобками?
D>Может, кавычками (если ты их не забил уже)
Блочная цитата использует.
D>, а цитата частный случай ссылки?
Ничего общего вроде бы. Блочная цитата это то, что сейчас выделяется тегом [q]. А одинарные кавычки в русской раскладке отсутствуют.
AVK>Есть одна проблема — сиволов [|] нет в русской раскладке. Но чем их заменить у меня идей нет. Двойными или тройными обычными скобками?
Мдямс. Об этом я как-то не подумал.
С другой стороны, насколько это необходимо? Ориентируясь на собственный опыт — раскладка меняется постоянно, десятки раз на дню: документы, комментарии, заметки и тексты, часть поисковых запросов пишутся на русском; адреса в браузере, код, команды в консоли, часть запросов в гугл — на английском, соответственно нажатие alt+shift уже отработано до автоматизма.
SO>С другой стороны, насколько это необходимо?
Необходимость переключения раскладки существенно замедляет набор и делает его менее комфортным, а так же иногда приводит к ошибкам с не той раскладкой. Поэтому мне кажется, что в часто используемых конструкциях без смены раскладки желательно обойтись. При этом для редких вещей, типа суперскрипта, это уже не так важно.
SO>>5. Код и цитирование
SO>>Какие альтернативы есть? Тут ошибиться в выборе нельзя, иначе потом будет мучительно больно.
AVK>Альтернатив не очень много. Помимо двойных и тройных {} я встречал 4-5 символов =, но это писать больше. В маркдауне используется grave accent, но у некоторых этот символ используется для переключения раскладки. Еще есть выделение кода 4 пробелами с начала строки, тут я вообще затрудняюсь оценить, насколько оно удобно. Ббшный [code][/code] тоже применяется, но он очень многословен. Остальные варианты довольно экзотичны, но если кто знает какой интересный вариант — можно обсудить.
После некоторого осмысления, вариант с тройными скобками кажется вполне допустимым.
Кстати, а до двух скобок получится сократиться?
SO>После некоторого осмысления, вариант с тройными скобками кажется вполне допустимым.
SO>Кстати, а до двух скобок получится сократиться?
ХЗ. В принципе — наверное да.
Ну и по реализации. ИМХО лучше делать code->AST->html, потому что на конце может быть не только html. Может банальность сказал и уже говорилось, тогда извините.
A>Ну и по реализации. ИМХО лучше делать code->AST->html
Я об этом в стартовом сообщении написал.
A>потому что на конце может быть не только html
Это как раз ерунда. Куда важнее, что есть алгоритмы, прежде всего подготовка цитирования, где парсинг тоже нужен. Сейчас такой код частично дублируется, а прикрутить дополнительные вещи типа специального цитирования каких то конструкций довольно трудно.
AVK>У существующего форматтера есть целый ряд недостатков:
Микс:
=Header
Header
==HeaderHeader
===HeaderHeader
...\iitalic on\iitalic off — italic
\bbold on\bbold off — bold
\c \lcpp — code
class CFoo {
...
\c
и тп.
M>Микс:
Не понял что ты хотел сказать.
AVK>Добавил синтаксис для таблиц, учел некоторые пожелания. Ссылка та же — https://bitbucket.org/andrewvk/rsdn.format/wiki/Specification
А вот ещё. Вот это *вообще* не будет работать:
Так никто не будет делать. Код копипейстится откуда-нибудь, где его проверяли на то, что он компилируется (или не компилируется) и работает (не работает), после чего его не трогают.
Допустимый способ выделения чего-либо в программном коде — подстрочное подчёркивание или стрелочка в комментарии:
C>Так никто не будет делать. Код копипейстится откуда-нибудь, где его проверяли на то, что он компилируется (или не компилируется) и работает (не работает), после чего его не трогают.
Исходя из такой логики, [b] внутри кода сейчас тоже не работает. Однако факты нам говорят, что все же работает. Наверное, потому что не всегда копипастят, а когда копипастят, то могут подправить.
C>// ^^^^ так делать нельзя!
И как, будем для каждого языка писать парсер комментариев?
AVK> Исходя из такой логики, [b] внутри кода сейчас тоже не работает. Однако факты нам говорят, что все же работает. Наверное, потому что не всегда копипастят, а когда копипастят, то могут подправить.
Допустить ошибку форматирования в исходнике гораздо проще, нежели в простом тексте. Я бы вообще оставил исходный код в покое кроме подсветки синтаксиса и, возможно, нумерации строк (опционально).
C>>Так никто не будет делать. Код копипейстится откуда-нибудь, где его проверяли на то, что он компилируется (или не компилируется) и работает (не работает), после чего его не трогают.
AVK>Исходя из такой логики, [b] внутри кода сейчас тоже не работает. Однако факты нам говорят, что все же работает. Наверное, потому что не всегда копипастят, а когда копипастят, то могут подправить.
[b] — гораздо менее частотная последовательность, чем *. Даже взятие элемента массива по индексу i встречается сильно реже, чем умножение и разыменование указателя/итератора. А то ещё бывают комментарии (*в Паскале*) и /*в Си-подобных*/, их тоже будем выделять?
C>[b] — гораздо менее частотная последовательность, чем *.
Поэтому внутри кода * двойная. Мало? Можно сделать тройную.
C>>[b] — гораздо менее частотная последовательность, чем *.
AVK>Поэтому внутри кода * двойная. Мало? Можно сделать тройную.
Не мало, но глупо. Думаю, ты и сам пошлешь свою идею по дальше, после пары "а черт!..." при копипасте кода.
ЗЫ
работают в коде отлично только потому, что без закрывающего они не обрабатываются. А с ним вероятность появления этого дела в коде стремится к нулю.
ЗЗЫ
Вообще, от добра добра не ищут. Текущий формат вполне удобен. Имеет смысл развивать его, а не выдумывать разную муру. В нем есть явные неудобства. Я бы выделил неудобные заголовки, списки и таблицы. Вот нужно подумать как их упростить. С зоголовками все просто. !!! ли === всех устроит. Со списками тоже не сложно. ## отлично подходя. С таблицами все сложнее, но тоже решаемо.
Что до трудностей ручного написания ББ-тегов, то их никто руками не пишет. На то есть тулбар.
Ну, а для упрощения форматирования имеет смысл делать визивидж-редктор, а не колдовать с форматами.
ЗЗЗЫ
Что касается технической стороны, то это не особой проблемой не является. Мы на этом уже всех собак съели.
VD>Не мало, но глупо. Думаю, ты и сам пошлешь свою идею по дальше, после пары "а черт!..." при копипасте кода.
Ну и? Твои предложения?
VD> работают в коде отлично только потому, что без закрывающего они не обрабатываются.
Я не планировал подобное поведение менять. Скорее наоборот, усложнять, чтобы заодно проверялось соотношение с границами слова.
VD>Вообще, от добра добра не ищут. Текущий формат вполне удобен.
Лично мне — нет. Можешь завести голосование.
VD>Что до трудностей ручного написания ББ-тегов, то их никто руками не пишет. На то есть тулбар.
Потому и не пишет, что жутко неудобно.
VD>Ну, а для упрощения форматирования имеет смысл делать визивидж-редктор, а не колдовать с форматами.
Сделай.
VD>Что касается технической стороны, то это не особой проблемой не является. Мы на этом уже всех собак съели.
Мне как то с ваших собак никакого прибытка. Что ты, что WH для сайта ничего не пишете, только флеймы разводите.
VD>Что до трудностей ручного написания ББ-тегов, то их никто руками не пишет. На то есть тулбар.
Глупости. Зачем отрывать руку от клавиатуры и целиться мышью в кнопку, если можно написать тэг?
VD>Ну, а для упрощения форматирования имеет смысл делать визивидж-редктор, а не колдовать с форматами.
WYSIWYG — давить.
VD>Что до трудностей ручного написания ББ-тегов, то их никто руками не пишет. На то есть тулбар.
Только руками и пишу. Гораздо быстрее, чем тянуться за мышью.
* "Звёздочка" в каждой ячейке — заголовке (будет трансформирована в <th>)
* Выравнивание по левой/правой сторонам, центру в зависимости от расположения текста в ячейке
Возможно ещё colspan, rowspan добавить.
SO>Дополнения:
SO>* "Звёздочка" в каждой ячейке — заголовке (будет трансформирована в <th>)
SO>* Выравнивание по левой/правой сторонам, центру в зависимости от расположения текста в ячейке
SO>
Я таблички еще днем добавил. Отличие от твоего варианта только одно — у меня достаточно звездочки в первой ячейке. Потому что в одной строке и заголовки и обычные ячейки — малополезная штука, так зачем дублировать.
SO>Возможно ещё colspan, rowspan добавить.
Можно, но как?
SO>>* Выравнивание по левой/правой сторонам, центру в зависимости от расположения текста в ячейке
SO>>
AVK>Я таблички еще днем добавил. Отличие от твоего варианта только одно — у меня достаточно звездочки в первой ячейке. Потому что в одной строке и заголовки и обычные ячейки — малополезная штука, так зачем дублировать.
Для клиента не нужны. Для разработчика парсера — хз.
+ я выравнивание в ячейках обозначил.
SO>>Возможно ещё colspan, rowspan добавить.
AVK>Можно, но как?
Позаимствовано из TiddlyWiki. Не верх изящества, однако работает
SO>Для клиента не нужны. Для разработчика парсера — хз.
Для парсера тоже не нужны.
SO>+ я выравнивание в ячейках обозначил.
Понял.
SO>>>Возможно ещё colspan, rowspan добавить.
AVK>>Можно, но как?
SO>
SO>
SO>Позаимствовано из TiddlyWiki. Не верх изящества, однако работает
Опять тильда, а так приемлемо.
AVK>Опять тильда, а так приемлемо.
Согласен.
Как альтернатива — "^". Придётся переключать раскладку, но rowspan достаточно редкая операция, поэтому больших затруднений не будет.
AVK>Еще такой вопрос — в некоторых форматтерах есть такая штука как плашки. Насколько оно нам нужно?
Что это вообще?
A>Что это вообще?
Шаблонное форматирование. Т.е. ты описываешь шаблон, без параметров или с каким то их количеством, и потом просто используешь его по имени с передачей значений параметров, если необходимо.
A>>Что это вообще?
AVK>Шаблонное форматирование. Т.е. ты описываешь шаблон, без параметров или с каким то их количеством, и потом просто используешь его по имени с передачей значений параметров, если необходимо.
Макросы что ли? Ну, по идее, любое форматирование может рассматриваться как частный случай макроса.
A>Макросы что ли?
Можно и так сказать
A> Ну, по идее, любое форматирование может рассматриваться как частный случай макроса.
Тогда это метамакрос.
AVK>Тогда это метамакрос.
Макрос всегда — мета.
AVK>Еще такой вопрос — в некоторых форматтерах есть такая штука как плашки. Насколько оно нам нужно?
Пока неясно
Ещё идея в копилку. Мы, пока что, при обсуждении синтаксиса исходим из абсолютной примитивности редактора разметки. В то же время даже для браузера это не верно, не говоря уже об отдельном приложении.
То есть если меня спросить что проще и логичнее набрать
мама **мыла** раму
или
мама [Ctrl+B]мыла[Ctrl+B] раму (где [Ctrl+B] может вставлять любой неудобный для набора код форматирования)
то я голосую за второй вариант. Мы все регулярно пользуемся клавиатурными cокращениями, так что ничего нового тут нет. Тем кто мало набирает всё равно, а тем кто много, удобнее. Ведь даже если взять символ /. Да, он есть в обеих раскладках, но на разных клавишах, а это сводит на нет всю выгоду.
A>То есть если меня спросить что проще и логичнее набрать
A>мама **мыла** раму
A>или
A>мама [Ctrl+B]мыла[Ctrl+B] раму (где [Ctrl+B] может вставлять любой неудобный для набора код форматирования)
A>то я голосую за второй вариант.
+1 и я даже писал Greasemonkey-скрипт для таких вещей. Только, во-первых, по одному нажатию вставляется сразу пара кодов (открывающий и закрывающий) и курсор ставится между ними. Это если нет выделения. А если выделение есть, то оно заключается в пару кодов и они тоже включаются в выделение.
А во-вторых, у кого-нибудь может возникнуть соблазн развить идею до WYSIWYG-редактора, и вот это я уже приветствовать не могу.
A>то я голосую за второй вариант. Мы все регулярно пользуемся клавиатурными cокращениями, так что ничего нового тут нет.
Только вот в разных браузерах и ОСях эти клавиатурные сокращения моугт быть зарезервированы, например. Плюс они не покрывают всех вариантов разметкм
A>>то я голосую за второй вариант. Мы все регулярно пользуемся клавиатурными cокращениями, так что ничего нового тут нет.
M>Только вот в разных браузерах и ОСях эти клавиатурные сокращения моугт быть зарезервированы, например. Плюс они не покрывают всех вариантов разметкм
Согласен, что свободных клавиатурных сокращений не так уж много. Но вот, например, Ctrl+U в Firefox это View Source. Насколько часто надо смотреть исходный код страницы при наборе сообщения?
M>>Только вот в разных браузерах и ОСях эти клавиатурные сокращения моугт быть зарезервированы, например. Плюс они не покрывают всех вариантов разметкм
A>Согласен, что свободных клавиатурных сокращений не так уж много. Но вот, например, Ctrl+U в Firefox это View Source. Насколько часто надо смотреть исходный код страницы при наборе сообщения?
Вопрос не только об этом. Вопрос и о том, кто будет запоминать все шорткаты? А их может получиться очень и очень немало. Каждый раз тянуться за мышкой, чтобы тыкать что-то в тулбаре? Не, увольте
A>>Согласен, что свободных клавиатурных сокращений не так уж много. Но вот, например, Ctrl+U в Firefox это View Source. Насколько часто надо смотреть исходный код страницы при наборе сообщения?
M>Вопрос не только об этом. Вопрос и о том, кто будет запоминать все шорткаты? А их может получиться очень и очень немало. Каждый раз тянуться за мышкой, чтобы тыкать что-то в тулбаре? Не, увольте
Во-первых, шорткаты будут по возможности стандартными. Во-вторых, запомнит любой кто будет часто польоваться. В-третьих, речь идёт о часто употребляемых тегах форматирования, а не о всех вообще.
Скажем для форматирования кода в любом случае надо будет переключить раскладку на английскую чтобы набрать название языка программирования.
A>Во-первых, шорткаты будут по возможности стандартными. Во-вторых, запомнит любой кто будет часто польоваться. В-третьих, речь идёт о часто употребляемых тегах форматирования, а не о всех вообще.
В янусе оно так уже сейчас. Только это не отменяет необходимости удобного формата разметки.
A>>Во-первых, шорткаты будут по возможности стандартными. Во-вторых, запомнит любой кто будет часто польоваться. В-третьих, речь идёт о часто употребляемых тегах форматирования, а не о всех вообще.
AVK>В янусе оно так уже сейчас. Только это не отменяет необходимости удобного формата разметки.
В Янусе я могу не трогая мыши, ничего не выделяя, набрать "привет Ctrl+B мир Ctrl+B" и получитcя "привет мир"?
Что будем делать с тэгами «вставить ссылку», «вставить изображение», «вставить кусок кода», «вставить список», «вставить цитату»? Об этом тоже идет речь, а не только о том, как выделить кусок текста полужирным или курсивом
A>Скажем для форматирования кода в любом случае надо будет переключить раскладку на английскую чтобы набрать название языка программирования.
Переключили, и дальше что? Мне все равно хочется набрать какое-то минмиальное количество символов, а не запоминать какой-нить «Ctrl+Shift+K» для вставки кода
A>>Во-первых, шорткаты будут по возможности стандартными. Во-вторых, запомнит любой кто будет часто польоваться. В-третьих, речь идёт о часто употребляемых тегах форматирования, а не о всех вообще.
M>Что будем делать с тэгами «вставить ссылку», «вставить изображение», «вставить кусок кода», «вставить список», «вставить цитату»? Об этом тоже идет речь, а не только о том, как выделить кусок текста полужирным или курсивом
Надо подумать. Мне не очень нравится полный уход от bbcode, потому что получается набор сиюминутных хаков, вместо логичной, пусть и многословной, системы.
A>>Скажем для форматирования кода в любом случае надо будет переключить раскладку на английскую чтобы набрать название языка программирования.
M>Переключили, и дальше что? Мне все равно хочется набрать какое-то минмиальное количество символов, а не запоминать какой-нить «Ctrl+Shift+K» для вставки кода
Это вопрос пользовательского интерфейса вообще, а не кодов форматирования. Если, например, после вставки из буфера редактор сам поймёт что это код на языке программирования, то не всё ли равно как это будет записано?
В случаях, когда текст должен содержать некоторую зарезервированную форматтером последовательность символов, например "//", тильда может отменять форматирование. Т.е. при наборе "~//", получим "//".
SO>Сырая идея на осмысление.
SO>В случаях, когда текст должен содержать некоторую зарезервированную форматтером последовательность символов, например "//", тильда может отменять форматирование. Т.е. при наборе "~//", получим "//".
В креоле так, да. Только опять проблемы с раскладкой — тильда может использоваться для переключения раскладок.
AVK>В креоле так, да. Только опять проблемы с раскладкой — тильда может использоваться для переключения раскладок.
Как вариант — бэкслэш.
AVK>>В креоле так, да. Только опять проблемы с раскладкой — тильда может использоваться для переключения раскладок.
SO>Как вариант — бэкслэш.
Принято
SO>В случаях, когда текст должен содержать некоторую зарезервированную форматтером последовательность символов, например "//", тильда может отменять форматирование. Т.е. при наборе "~//", получим "//".
Тогда уж не тильда, а классический бэкслэш. И да, такая практика есть, в старом Confluence это было.
C>Тогда уж не тильда, а классический бэкслэш.
Вопрос вкуса. С учётом специфики рсдн, слеши, конечно, будут ближе.
Нужно решить вопрос с жирным и курсивом — толи удваивать символы, толи воспользоваться предложением по ограничению комбинаций корректными для обычных скобок вариантами.
AVK>Обновил в соответствии с пожеланиями.
AVK>Нужно решить вопрос с жирным и курсивом — толи удваивать символы, толи воспользоваться предложением по ограничению комбинаций корректными для обычных скобок вариантами.
Голосую за удвоенные символы по причинам:
* простоты реализации
* привычности записи
Вот статистика от скрупулёзных коллег:
http://www.wikicreole.org/wiki/BoldAndItalicsReasoning
SO>Голосую за удвоенные символы по причинам:
SO>* простоты реализации
Это точно вторично по сравнению с удобством.
SO>* привычности записи
Тоже вопрос тонкий. Вики еще не настолько в нашу жизнь вошли.
SO>Вот статистика от скрупулёзных коллег:
Ну, если опираться только на статистику, тогда надо креолу реализовывать и не морочить людям голову Тем паче что sigle asterisk вполне заметную часть занимает, да и single slash не на последнем месте.
Ну ок, возьмем за базовый вариант удвоенные * и /. Что насчет подчеркивания — тоже удваиваем и утраиваем сабскрипт?
AVK>Что насчет подчеркивания — тоже удваиваем и утраиваем сабскрипт?
Удвоение, имхо, самое то.
SO>>* простоты реализации
AVK>Это точно вторично по сравнению с удобством.
SO>>* привычности записи
AVK>Тоже вопрос тонкий. Вики еще не настолько в нашу жизнь вошли.
Вообще говоря да.
Я когда впервые с вики-синтаксисом столкнулся был слегка изумлён, уж больно непривычно для глаза выглядел ("эта мешанина из закорючек ещё и работает?!"). Впрочем, порог входа в язык разметки минимальный, удалось освоиться быстро. И есть ощущение, что если человек хоть раз сталкивался с любым из языков разметки, для освоения нового достаточно посмотреть на небольшую шпаргалку, чтобы въехать в тему (сделать такую шпаргалку будет несложно).
Интересно, насколько часто посетители рсдн сталкивались с созданием статей в вики. Опрос, что ли замутить.
SO>Интересно, насколько часто посетители рсдн сталкивались с созданием статей в вики. Опрос, что ли замутить.
http://www.rsdn.ru/poll/3671.aspx
Посмотрим через пару дней на результаты
SO>http://www.rsdn.ru/poll/3671.aspx
SO>Посмотрим через пару дней на результаты
По состоянию на 24 августа 17:34 — из 33 ответивших 20 по большому счёту с вики-синтаксисом не сталкивались. Мне казалось с работой (и синтаксисом) вики знакомо чуть большее количество людей.
Подождем ещё несколько дней, поднаберётся статистика, тогда можно будет интерпретировать результаты.
SO>А как предполагается осуществлять внедрение нового движка?
Видимо, флажок в БД и сразу два форматтера параллельно на первое время. И возможность выбрать разметку при написании сообщения. А дальше по статистике — если старым форматтером будет мало народу пользоваться, то выкинуть возможность использования и, в перспективе, сконвертировать старые сообщения в новый формат.
AVK>Видимо, флажок в БД и сразу два форматтера параллельно на первое время. И возможность выбрать разметку при написании сообщения. А дальше по статистике — если старым форматтером будет мало народу пользоваться, то выкинуть возможность использования и, в перспективе, сконвертировать старые сообщения в новый формат.
Разумно.
AVK>Здравствуйте, ShaggyOwl, Вы писали:
SO>>А как предполагается осуществлять внедрение нового движка?
AVK>Видимо, флажок в БД и сразу два форматтера параллельно на первое время. И возможность выбрать разметку при написании сообщения. А дальше по статистике — если старым форматтером будет мало народу пользоваться, то выкинуть возможность использования и, в перспективе, сконвертировать старые сообщения в новый формат.
Тогда будет проблема с цитированием при ответах — либо ты используешь тот же форматтер, что и автор исходного сообщения, либо конвертируешь всё в свой любимый синтаксис вручную.
RT>Тогда будет проблема с цитированием при ответах — либо ты используешь тот же форматтер, что и автор исходного сообщения, либо конвертируешь всё в свой любимый синтаксис вручную.
Ну да.
AVK>У существующего форматтера есть целый ряд недостатков:
Ха-ха-ха (смеются немерлисты)
AVK>В связи с чем предлагаю:
AVK>1) Поднять руку тому, кому эта тема вообще интересна.
А почему в этой теме ни Влада2, ни ВолфХаунда?
_R_>А почему в этой теме ни Влада2, ни ВолфХаунда?
Спрашивай у них. Пока что все угрозы переписать весь сайт, форматтер, etc заканчивались переписыванием компилятора Немерле.
AVK>Спрашивай у них. Пока что все угрозы переписать весь сайт, форматтер, etc заканчивались переписыванием компилятора Немерле.
А может просто случая не было? Прописать волшебный пендаль?
1. **(жирный), // (наклонный), -- (перечёркнутый), ^^ (верхний индекс), __ (нижний индекс)
2. Ссылки ((link)), ((link|title))
3. Оформление строчного кода {{ruby {code} }}
4. Оформление блоков кода
{{cpp
}}
Если возражений не последует, обновлю.
AVK>Если возражений не последует, обновлю.
Ок.
Я правильно понимаю, что в первом приближении работа над синтаксисом близка к завершению?
SO>Я правильно понимаю, что в первом приближении работа над синтаксисом близка к завершению?
Думаю, да.
SO>1. **(жирный), // (наклонный), -- (перечёркнутый), ^^ (верхний индекс), __ (нижний индекс)
Поправка. Двойная __ — подчеркивание, тройная ___ — нижний индекс.
SO>3. Оформление строчного кода {{ruby {code} }}
SO>4. Оформление блоков кода
SO>{{cpp
SO>}}
Для унификации тогда уж лучше
{{cpp{
...
}}}
Еще для блочного кода надо добавить синтаксис указания, что код надо показать в свернутом блоке:
+{{cpp{
...
}}}
Забыли, кстати, про [cut].
SO>>1. **(жирный), // (наклонный), -- (перечёркнутый), ^^ (верхний индекс), __ (нижний индекс)
AVK>Поправка. Двойная __ — подчеркивание, тройная ___ — нижний индекс.
Ок.
AVK>Для унификации тогда уж лучше
AVK>{{cpp{
AVK> ...
AVK>}}}
+1
AVK>Еще для блочного кода надо добавить синтаксис указания, что код надо показать в свернутом блоке:
+1
AVK>Забыли, кстати, про [cut].
Мм.. А что это?
SO>Мм.. А что это?
Свернутый блок.
AVK>Свернутый блок.
AVK>
Понятно. И по-хорошему, желательно, чтобы под катом сохранялось форматирование.
SO>Понятно. И по-хорошему, желательно, чтобы под катом сохранялось форматирование.
Верно. Ну и для блочной цитаты, наверное, тоже версию с + нужно:
SO>Понятно. И по-хорошему, желательно, чтобы под катом сохранялось форматирование.
Добавил такой синтаксис:
AVK>Добавил такой синтаксис:
Красота.
Я сегодня вечерком вычитаю спецификацию.
Есть понимание, как будем работать дальше?
По цитированию предложение.
Либо делать все предыдущее цитирование под катом,либо оставить как есть, но если цитата длинная, то все что длиннее 5 строк заменяется на ..., если хочешь именно этот текст процитировать, то делаешь усиление ___ваыв___ . В текущем механизме генерации сообщений цитирование подбешивает тем, что приходится делать работу по форматированию авто-генерированного текста, чтобы не сидеть в бане.