Простые, логичные, легко запоминающиеся правила разметки.
Больше возможностей (подчёркивание, цвет текста, выравнивание, таблицы без заголовков, объединение ячеек в таблицах).
Лучше поддержка вложенности элементов разметки.
Проще реализация (всего ~800 строк кода на Python).
И почему бы не использовать уже присутствующие на клавиатуре парные символы — такие, как фигурные скобки?
Фигурные скобки уже используются в пк-разметке для древовидного выражения мыслей (: древопись :).
Почему не круглые/квадратные/угловые скобки? Не знаю, внешне (в шрифтах Tahoma, Verdana, Courier New) парные кавычки имхо подходят лучше, чем скобки.
И правда ли нужны именно парные символы?
Ну, они дают возможность неограниченной вложенности.
https://en.wikipedia.org/wiki/M4_(computer_language):
Unlike most languages, strings in m4 are quoted using the backtick (`) as the starting delimiter, and apostrophe (') as the ending delimiter. The use of separate starting and ending delimiters allows for the arbitrary nesting of quotation marks in strings…
В отличие от большинства других языков, строки в m4 берутся в кавычки используя символ обратной кавычки (`) в качестве открывающей кавычки, и символ апострофа (') в качестве закрывающей. Использование отдельных символов для открывающей и закрывающей кавычек предоставляет возможность неограниченной вложенности кавычек внутри строк...
Речь здесь идёт про недостаток строк в непарных кавычках (например "таких") в том, что внутрь строки нельзя вкладывать другие строки, например:
system("mkdir "имя папки с пробелами"")
Так не работает (и не может работать).
А так может работать, если язык программирования и ОС поддерживают парные кавычки:
Не хотите попробовать свои силы в реализации задачи, описанной в моём комментарии выше (конвертер в Markdown)?
Парсить пк-разметку достаточно просто (оригинальная реализация насчитывает всего ~800 строк кода на Python).
Есть одна достаточно несложная, но актуальная [и, надеюсь, вполне себе интересная] задача — написать преобразователь пк-разметки в Markdown {сразу оговорюсь, что нужно только в одну сторону, а для чего задача — хочу презентации на пк-разметке писать, а готовые тулзы работают либо с Markdown, либо с HTML [и у меня есть такое предположение, что с Markdown работают лучше, чем с HTML]}. Если кто хочет попробовать, просьба ответить на этот комментарий. (Также прошу написать про опыт работы с тулзами вроде remarkjs.com, если у кого был.)
[P.S. Оригинальную реализацию (преобразователь/конвертер в HTML) pqmarkup.py трогать не хочется, да и незачем, я считаю, нагружать её ещё и Markdown-ом.]
Благодарю за ссылку, но на практике использовать для популяризации пк-разметки такую штуку скорее всего никак не получится. Слишком сложно. Должен быть очень простой способ добавить поддержку ввода нестандартных символов, чтобы его могли массово использовать. Желательно умещающийся в один твит.
Например:
Установите AutoHotkey.
Добавьте эти две строчки в файл-скрипт настроек:
Alt & 9:: SendInput {‘}
Alt & 0:: SendInput {’}
[P.S. И я не просто выбрал эти символы, я дождался года/кода этих символов, чтобы опубликовать статью именно в этот год (почему не опубликовал статью 1 января 2018? Можно сказать, так получилось, что не было интернета в тот момент времени.).]
То есть, код базовой реализации определяет/задаёт точную спецификацию оригинальной разметки.
И для Markdown (и даже CommonMark), насколько мне известно, также нет официальной BNF/EBNF/ABNF (хотя есть неофициальные, например github.com/Domysee/MarkdownEbnf).
непонятны многие вещи, например как вы экранируете спецсимволы.
Посредством Дополнительные возможности форматирования. «Сырой»\Raw HTML возможно вставить произвольный HTML, в том числе спецсимволы (как в формате HTML entities, так и просто в виде символов).
Но, в отличие от других разметок, в пк-разметке экранировать требуется гораздо меньше спецсимволов, и спецсимволы можно вставлять прямо в код как есть.
То есть если детерминизм есть, нам нужна вторая вселенная, чтобы моделировать нашу вселенную.
Ну да. Так и есть — вторая [зеркальная] Вселенная [моделирует/]симулирует\estimates нашу, а наша [первая] Вселенная моделирует[/симулирует]\estimates вторую. Таким образом, вся Жизнь в Космосе поддерживается парами близнецовых Вселенных, [моделирующих/]симулирующих друг друга. (: Так всё и работает. :)
Посмотрел. Занятно. Но почему не взлетело — вполне очевидно:
Редактирование в "текстовом" режиме только моноширного текста теперь стало совсем неактуально.
Формат сохранения текстовых файлов — своеобразный и скорее не текстовый, а двоичный.
Антивирус [стандартный Windows Defender] на этот редактор ругается (и не только).
А вот то, что взлетит, мне тоже понятно {за счёт чего — нужно просто много/долго {как минимум, дольше, чем на "неправильные"} смотреть на "правильные" вещи} — нужен микс из:
Sublime Text. (ИМХО, пока что лучший инструмент для кодера/программиста, особенно, любящего вносить свои правки в поведение редактора. Дополнительным открытием для меня стало то, что панель инструментов с красивыми кнопками в редакторе для кода практически и не нужна и что вполне можно обойтись без продвинутого окна настроек посредством грамотной документации и продуманных файлов настроек в удобочитаемом формате (JSON или даже что-то попроще).)
PyCharm. (Прежде всего за отладчик Python.)
Microsoft Visual Studio. (Отладчик C++/C# в студии лучше, чем в PyCharm — советую JetBrains добавить хотя бы отображение многострочных строк.)
Notepad++, Atom и Visual Studio Code. (В плане открытости [исходного кода].)
Хотя Atom и Visual Studio Code очень хочется исключить из этого списка за то, что их разработчики выбрали "неправильную" (тормозную) платформу.
Замечание: на Хабре присутствует такой баг — кнопка Предпросмотр на страницах habrahabr.ru/sandbox/add и habrahabr.ru/topic/add работает по-разному! Точнее, галочка «Отключить автоматические переносы строк и создание ссылок» просто не работает при добавлении статьи в Песочницу.
(О таком, безусловно, нужно писать прежде всего в баг-трекер, но решил оставить комментарий тут как оправдание несколько неказистого оформления статьи — получилось нечто среднее между тем, как поправил оформление статьи модератор и тем как я приглядывался к Предпросмотру [а он оказывается неправильный...] и старался получить такой вид статьи, который хотелось).
(Добавил в статью ‘[на любом языке программирования]’.)
Ещё один пример:
**Этот текст в Markdown
не выделится жирным шрифтом**
*
‘а этот (на пк-разметке)— выделится [жирным]
’Хотя в Markdown допускается вложенное форматирование, например так:
_Какой-либо **жирный текст** внутри курсива_
Оно более ограниченно и не сработает в случае когда захочется например все элементы списка выделить курсивом.
Так код:
*1. Первый элемент списка
2. Второй элемент списка
*
В Markdown отображается как:
В то время как код на пк-разметке:
~‘1. Первый элемент списка
2. Второй элемент списка
’
Выводится корректно:
Фигурные скобки уже используются в пк-разметке для древовидного выражения мыслей (: древопись :).
Почему не круглые/квадратные/угловые скобки? Не знаю, внешне (в шрифтах Tahoma, Verdana, Courier New) парные кавычки имхо подходят лучше, чем скобки.
Ну, они дают возможность неограниченной вложенности.
Речь здесь идёт про недостаток строк в непарных кавычках (например "таких") в том, что внутрь строки нельзя вкладывать другие строки, например:Так не работает (и не может работать).
А так может работать, если язык программирования и ОС поддерживают парные кавычки:
Не хотите попробовать свои силы в реализации задачи, описанной в моём комментарии выше (конвертер в Markdown)?
Парсить пк-разметку достаточно просто (оригинальная реализация насчитывает всего ~800 строк кода на Python).
[P.S. Оригинальную реализацию (преобразователь/конвертер в HTML) pqmarkup.py трогать не хочется, да и незачем, я считаю, нагружать её ещё и Markdown-ом.]
Благодарю за ссылку, но на практике использовать для популяризации пк-разметки такую штуку скорее всего никак не получится.
Слишком сложно.Должен быть очень простой способ добавить поддержку ввода нестандартных символов, чтобы его могли массово использовать. Желательно умещающийся в один твит.Например:
Установите AutoHotkey.
Добавьте эти две строчки в файл-скрипт настроек:
Alt & 9:: SendInput {‘}
Alt & 0:: SendInput {’}
или
Установите Sublime Text 3.
Установите плагин pqmarkup.
или
Установите новый редактор со встроенной поддержкой пк-разметки.
Для ввода символов парных кавычек ничего настраивать в нём не нужно.
Дополнительные возможности форматирования. Вставка исходного кода
Дополнительные возможности форматирования. Отключение пк-форматирования
Дополнительные возможности форматирования. «Сырой»\Raw HTML
[P.S. И я не просто выбрал эти символы, я дождался года/кода этих символов, чтобы опубликовать статью именно в этот год (почему не опубликовал статью 1 января 2018? Можно сказать, так получилось, что не было интернета в тот момент времени.).]
А почему EBNF, а не ABNF?
Но в данном случае я руководствуюсь принципом:
То есть, код базовой реализации определяет/задаёт точную спецификацию оригинальной разметки.
И для Markdown (и даже CommonMark), насколько мне известно, также нет официальной BNF/EBNF/ABNF (хотя есть неофициальные, например github.com/Domysee/MarkdownEbnf).
Посредством Дополнительные возможности форматирования. «Сырой»\Raw HTML возможно вставить произвольный HTML, в том числе спецсимволы (как в формате HTML entities, так и просто в виде символов).
Но, в отличие от других разметок, в пк-разметке экранировать требуется гораздо меньше спецсимволов, и спецсимволы можно вставлять прямо в код как есть.
Visual Studio Code или MS Visual C++?
В плане тормознутости PyCharm (аналогично PhpStorm, т.к. обе эти IDE на одной платформе) — согласен, но лучшего отладчика для Python я не нашёл.
А как обстоят дела с отладкой PHP в этой «вашей» VC?
Посмотрел. Занятно. Но почему не взлетело — вполне очевидно:
А вот то, что взлетит, мне тоже понятно {за счёт чего — нужно просто много/долго {как минимум, дольше, чем на "неправильные"} смотреть на "правильные" вещи} — нужен микс из:
Хотя Atom и Visual Studio Code очень хочется исключить из этого списка за то, что их разработчики выбрали "неправильную" (тормозную) платформу.
(О таком, безусловно, нужно писать прежде всего в баг-трекер, но решил оставить комментарий тут как оправдание несколько неказистого оформления статьи — получилось нечто среднее между тем, как поправил оформление статьи модератор и тем как я приглядывался к Предпросмотру [а он оказывается неправильный...] и старался получить такой вид статьи, который хотелось).