Comments 65
Зачем?
Даже в разметке.
Вот, кстати, тоже подумал — "Зачем?" А потом мгновенно пришел ответ — "Потому что!". И это правильно, на самом деле. Почему бы и нет. Просто так.
А так, кроме этого, вполне себе ничего.
Мазохизм только если вы не знаете, как настроить окружение. Или не можете себе этого позволить (к примеру, потому что компьютер не ваш).
Это относится к варианту «не знаете, как настроить». Нужные действия вполне можно автоматизировать, если вы действительно часто меняете аккаунты.
xzibit.jpeg
и вообще, как бы ни говорили про эпоху Юникод, но я из эпохи ASCII и подозрителен к любым символам, у которых код больше 128
(О таком, безусловно, нужно писать прежде всего в баг-трекер, но решил оставить комментарий тут как оправдание несколько неказистого оформления статьи — получилось нечто среднее между тем, как поправил оформление статьи модератор и тем как я приглядывался к Предпросмотру [а он оказывается неправильный...] и старался получить такой вид статьи, который хотелось).
с помощью программы AutoHotkey назначить глобальные горячие клавиши для ввода любых спец-символовaЯ вам по секрету скажу, можно просто раскладку клавиатуры сменить. В том числе на самодельную.
Только тс-с-с..!
Благодарю за ссылку, но на практике использовать для популяризации пк-разметки такую штуку скорее всего никак не получится. Слишком сложно. Должен быть очень простой способ добавить поддержку ввода нестандартных символов, чтобы его могли массово использовать. Желательно умещающийся в один твит.
Например:
Установите AutoHotkey.
Добавьте эти две строчки в файл-скрипт настроек:
Alt & 9:: SendInput {‘}
Alt & 0:: SendInput {’}
или
Установите Sublime Text 3.
Установите плагин pqmarkup.
или
Установите новый редактор со встроенной поддержкой пк-разметки.
Для ввода символов парных кавычек ничего настраивать в нём не нужно.
Посмотрел. Занятно. Но почему не взлетело — вполне очевидно:
- Редактирование в "текстовом" режиме только моноширного текста теперь стало совсем неактуально.
- Формат сохранения текстовых файлов — своеобразный и скорее не текстовый, а двоичный.
- Антивирус [стандартный Windows Defender] на этот редактор ругается (и не только).
А вот то, что взлетит, мне тоже понятно {за счёт чего — нужно просто много/долго {как минимум, дольше, чем на "неправильные"} смотреть на "правильные" вещи} — нужен микс из:
- Sublime Text. (ИМХО, пока что лучший инструмент для кодера/программиста, особенно, любящего вносить свои правки в поведение редактора. Дополнительным открытием для меня стало то, что панель инструментов с красивыми кнопками в редакторе для кода практически и не нужна и что вполне можно обойтись без продвинутого окна настроек посредством грамотной документации и продуманных файлов настроек в удобочитаемом формате (JSON или даже что-то попроще).)
- PyCharm. (Прежде всего за отладчик Python.)
- Microsoft Visual Studio. (Отладчик C++/C# в студии лучше, чем в PyCharm — советую JetBrains добавить хотя бы отображение многострочных строк.)
- Notepad++, Atom и Visual Studio Code. (В плане открытости [исходного кода].)
Хотя Atom и Visual Studio Code очень хочется исключить из этого списка за то, что их разработчики выбрали "неправильную" (тормозную) платформу.
Хотя Atom и Visual Studio Code очень хочется исключить из этого списка за то, что их разработчики выбрали "неправильную" (тормозную) платформу.
По этому поводу хочется спорить, потому что перешел на VC исключительно потому что PhpStorm от JetBrains (насколько бы он не был универсальным) постоянно подлагивает. Все относительно.
Visual Studio Code или MS Visual C++?
В плане тормознутости PyCharm (аналогично PhpStorm, т.к. обе эти IDE на одной платформе) — согласен, но лучшего отладчика для Python я не нашёл.
А как обстоят дела с отладкой PHP в этой «вашей» VC?
Хотя Atom и Visual Studio Code очень хочется исключить из этого списка за то, что их разработчики выбрали «неправильную» (тормозную) платформу.
VS Code во сравнению с Atom тормозит сильно меньше, но тут кое-чего скорее не хватает…
Вот так не работает: ~*‘жирный курсив’ (будет просто ~жирный), пишите так: ~‘*‘жирный курсив’’ или так: *‘~‘жирный курсив’’
ЧТОА? Можно увидеть EBNF вашей замечательной грамматики?
Это существенная черта языка, странно что вы упоминаете её очень вскользь.
Не такой уж язык и «облегчённый». Кроме того EBNF всё равно хотелось бы увидеть, иначе непонятны многие вещи, например как вы экранируете спецсимволы.
допускаются вложенные pq выражения.В Markdown также допускается вложенное форматирование (правда, в более ограниченных случаях):
guides.github.com/features/mastering-markdown:
_You **can** combine them_
А почему EBNF, а не ABNF?
Но в данном случае я руководствуюсь принципом:
https://www.youtube.com/...:То есть, код базовой реализации определяет/задаёт точную спецификацию оригинальной разметки.
"Code is Law"
И для Markdown (и даже CommonMark), насколько мне известно, также нет официальной BNF/EBNF/ABNF (хотя есть неофициальные, например github.com/Domysee/MarkdownEbnf).
непонятны многие вещи, например как вы экранируете спецсимволы.Посредством Дополнительные возможности форматирования. «Сырой»\Raw HTML возможно вставить произвольный HTML, в том числе спецсимволы (как в формате HTML entities, так и просто в виде символов).
Но, в отличие от других разметок, в пк-разметке экранировать требуется гораздо меньше спецсимволов, и спецсимволы можно вставлять прямо в код как есть.
Это существенная черта языка, странно что вы упоминаете её очень вскользь.
Хорошо, добавил в статью Обратите внимание, что использование отдельных символов для открывающей и закрывающей кавычек предоставляет возможность неограниченной вложенности элементов форматирования.
Синтаксический диабетик
Причины (впрочем, достаточно субъективные), почему я выбрал именно символы ‘’ (а не `´ или, скажем, «» или “”):
А вот я бы как раз выбрал очевидно зеркальные (в подавляющем большинстве шрифтов), независимо от того, идут они подряд или задом наоборот. Как заметили выше, сделать кастомную раскладку — не проблема. При частом использовании коды двух символов запоминаются с полпинка (для ненастроенного окружения) и, кроме того, именно за счёт того, что они идут не подряд — сложнее допустить ошибку. А так — они и выглядят почти одинаково (при нормальном размере шрифта а не увеличенном) и за счёт смежных позиций можно легко перепутать.
- По стандарту у картинок обязательно должен быть атрибут
alt
.
Markdown это вполне решает:![моя фотография](http://example.com/myphoto.jpg)
→<img alt="моя фотография" src="http://example.com/myphoto.jpg">
. А вот у Вас с этим явная проблема (во-первых,title
— не то же самое, чтоalt
, во-вторых, Вы разрешаете не указатьtitle
(точнее, не просто разрешаете не указать, Markdown тоже разрешает не указать, а синтаксически оформляете его как что-то «дополнительное»)). - Немозможность вставить в (англ., укр.) текст нормальную кавычку без дополнительных ухищрений — это, ИМХО, ппц. То есть Вы как бы плясали от того, что взяли два символа, которые меньше всего используются в русском тексте. Но:
- Вы попали на символы, которые дохрена используются в англ. тексте.
- Вы попали на символы, которые не просто дохрена используются в англ. тексте, а очень часто подпадают под автозамену в различных текстовых редакторах. В отличие от, например, Markdown'овских скобочек и пр., текстовые редакторы не относятся к одинарным кавычкам как к чему-то незыблемому и часто неявно меняют их с одних на другие, например LibreOffice и quora.com заменяют U+0027 (
He said me 'I don't know!'
) на U+2018 и U+2019 (He said me ‘I don’t know!’
). Т.о. копи-пейст pq-кода через «умный» редактор может его испортить (навставляв несимметричных U+2018 и U+2019). - Я б тогда на Вашем месте вообще уже какие-то неиспользуемые в нормальном тексте специальные Unicode-символы взял (а-ля и ). Но, по-моему, такая идея в любом случае гиблая, потому что, во-первых, надо иметь возможность представить pq-код внутри pq-кода, во-вторых, это фактически возврат в прошлое (см. control characters). Хотя, кто знает, может, история и пойдёт по спирали.
- Кстати, как у Вас с возможностью представить неотформатированный текст (исходный код, например)?
(а-ля и )(а-ля ▸ и ◂)
Кстати, как у Вас с возможностью представить неотформатированный текст (исходный код, например)?
Дополнительные возможности форматирования. Вставка исходного кода
Дополнительные возможности форматирования. Отключение пк-форматирования
Дополнительные возможности форматирования. «Сырой»\Raw HTML
[P.S. И я не просто выбрал эти символы, я дождался года/кода этих символов, чтобы опубликовать статью именно в этот год (почему не опубликовал статью 1 января 2018? Можно сказать, так получилось, что не было интернета в тот момент времени.).]
[P.S. Оригинальную реализацию (преобразователь/конвертер в HTML) pqmarkup.py трогать не хочется, да и незачем, я считаю, нагружать её ещё и Markdown-ом.]
Не хотите попробовать свои силы в реализации задачи, описанной в моём комментарии выше (конвертер в Markdown)?
Парсить пк-разметку достаточно просто (оригинальная реализация насчитывает всего ~800 строк кода на Python).
А чем это лучше того же markdown? И почему бы не использовать уже присутствующие на клавиатуре парные символы — такие, как фигурные скобки? И правда ли нужны именно парные символы?
А чем это лучше того же markdown?
- Простые, логичные, легко запоминающиеся правила разметки.
- Больше возможностей (подчёркивание, цвет текста, выравнивание, таблицы без заголовков, объединение ячеек в таблицах).
- Лучше поддержка вложенности элементов разметки.
- Проще реализация (всего ~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 "имя папки с пробелами"")
Так не работает (и не может работать).
А так может работать, если язык программирования и ОС поддерживают парные кавычки:
system(‘mkdir ‘имя папки с пробелами’’)
<b>Очень<i>длинное</b>слово</i>.
У вас невалидный HTML, тэги должны правильно вкладываться. Преобразуем в валидную форму, дальше очевидно.
<b>Очень</b><i><b>длинное</b>слово</i>
P.S. В HTML, кстати, такая разметка хоть и считается невалидной, но работает.
Хотя в Markdown допускается вложенное форматирование, например так:
guides.github.com/features/mastering-markdown:_Какой-либо **жирный текст** внутри курсива_
_You **can** combine them_
Оно более ограниченно и не сработает в случае когда захочется например все элементы списка выделить курсивом.
Так код:
*
1. Первый элемент списка
2. Второй элемент списка
*
В Markdown отображается как:
- Первый элемент списка
- Второй элемент списка
В то время как код на пк-разметке:
~‘
1. Первый элемент списка
2. Второй элемент списка
’
Выводится корректно:
- Первый элемент списка
- Второй элемент списка
Ещё один пример:
**Этот текст в Markdown
не выделится жирным шрифтом**
*‘
а этот (на пк-разметке)
— выделится [жирным]’
Новый облегчённый язык разметки текста на основе парных кавычек (pq)