LINUX.ORG.RU
ФорумTalks

Истинное real-time .md редактирование

 , , ,


0

2

Я не отрицаю, это изврат as is, но, мало ли у кого какие фетиши да развлечения, даже более – потребности. ИИТ я кричу о помощи и надеюсь соискать товарищей по беде/интересам.

Уже несколько лет с изрядной переодичностью я натыкаюсь на личную необходимость использования .md, так как plain/text скуден до форматирования в человекочитаемом виде, built-in костыли aka csv-like семейство несколько не про это, xml как с пушки по пчелам, html, выжимкой которого и является сабж перегружен для ввода.

Все бы ничего, но по какой - то неведомой мне причине разработчики софта для, а возможно и пользователи, .md воспринимают его так что изначально необходимо использование only plain/text, и только затем рендер красивенько и удобно читаемо во все что угодно, ну в тот же html. Почему же эти преимущества не использовать и в момент создания/редактирования документа, сохраняя при этом формат хранения читаемым (да и потенциально редактируемым), при острой необходимости, чем угодно, что может в plain/text ?

Суть .md в том чтобы с легкостью и удобством сообщать о форматировании, чтобы форматирование поддерживалось но при этом не выходило на первый план, не мешало что - ли. А то как это форматирование реализовано (какой - стиль там и т.д) это уже вопросы изменяемой реализации отображения этого форматирования.

Почему бы не парсить вводимое и не выводить результат in real-time, позволяя сразу оценить вносимые изменения ? Синтаксис ведь достаточно прост и регулярен. Я понимаю в CLI редакторах это не реализуемо, да и не очень надо, но, неужели в полноценном редакторе невозможно реализовать отображение/рендер simple html-like форматирования ? В том же браузере, можно на коленке ипользуя contenteditable страницу и JS на лету принимать во внимание синтаксис и вносить CSS, но то браузер, почему я должен делать это в браузере ?

Есть множество конкретно ориентированных для .md решений, открытых и закрытых, с разными интересными и не очень фишками. Но, изрядная доля из них все равно продолжает традицию, изложенную мной выше, когда в отдельном окне происходит редактирование информации в plain/text и в отдельном окне/приложении ее рендеринг.

Давно приглядываюсь e.g к Typora, моя концепция там снискала отклик, но это electron, да еще и проприетарщина, отдельное приложение для редактирования .md, которое завтра может испортиться или вообще загнуться. Хотелось бы более универсально-эффективного решения. Редактора текста as default с возможности реализации мной описанного за счет, ну, скажем плагина или дополнения. Все таки скакать нужно от основания.

Возможно используемый вами или вам известный редактор может что - то подобное ? Может вы имеете возможность направить мой взор на нечто что я до сих пор упускаю из виду ?

В любом случае, благодарю за уделенное мне внимание.


А теперь то же самое, но в одном предложении с максимум двенадцатью словами. Ну или хотя бы двумя.

textproc/retext?

mord0d ★★★★ ()

Возможно используемый вами или вам известный редактор может что - то подобное ? Может вы имеете возможность направить мой взор на нечто что я до сих пор упускаю из виду ?

Редактирую Markdown в различных IDE, например, в IntelliJ IDEA есть предпросмотр, хотя им я не пользуюсь.

EXL ★★★★★ ()

Для визивига есть Libre Office Writer. pandoc для дальнейшей перегонки в html и затем в markdown. Но это грязные извращения, не надо так делать.

peregrine ★★★★★ ()
Ответ на: комментарий от leave

В google images, по запросу pycharm markdown preview показывают два окна (сплит одного maybe) в одном plain в другом рендер. Похоже, меня ввели в заблуждение, вы, или google images.

oOoOo ()
Ответ на: комментарий от EXL

Вы планируете к этим данным более обращаться ? Может быть вносить правки ? Если нет, то это какой - то PDF получается, и смысл в .md несколько теряется. Если да, положим, вы ведете записи активно и обращаетесь к ним с правками несколько раз на дню. Удаляете неактуальное, добавляете многое. Неужели вам не предпочтительно наблюдать тот формат, для чего все это форматирование и введено ? Зачем оно тогда если и создание и использование происходит в plain/text ?

oOoOo ()
Ответ на: комментарий от oOoOo

Неужели вам не предпочтительно наблюдать тот формат, для чего все это форматирование и введено ?

Нет, не предпочтительно, так как Markdown абсолютно прозрачен для чтения без предпросмотра.

Зачем оно тогда если и создание и использование происходит в plain/text ?

Для красивого рендеринга в HTML на каком-нибудь GitHub или с помощью Pandoc.

EXL ★★★★★ ()
Ответ на: комментарий от peregrine

Если я верно понимаю, вы предлагаете создавать doc (или его открытые аналоги) в офисном текстовом процессоре, после чего, так или иначе трансфигурировать его (по возможности) в .md для хранения ?

На самом деле интересный ход, мысли… В данном случае конечно проще будет использовать нативный md редактор, удовлетворяющий изложенным в ТС-посте запросам, то есть сделав круг вернуться в исходную точку. Ведь это все тоже ограниченное, сферическое в вакууме решение, некий компромисс, неизвестно насколько адекватный в долгосрочной перспективе. А уж если задуматься о md - > doc-like, это уже совсем…

Та же typora несомненно хороша, по крайней мере, в 2018-ом, когда я ее рассматривал в качестве решения она была лучшим md редактором по моему мнению. Но, она определенно не лучший инструмент для работы с текстом так или иначе, не может выступать в роли той же IDE, не умеет в командный режим, банальные замены по регулярным правилам. Ее нельзя вызвать в качестве $EDITOR…

Я убежден в малой вероятности существования того о чем вопрошаю, от того и пишу «крик о помощи», между тем, ребята из typoraio ведь как - то дошли (безусловно ранее меня) до этой идеи, более того, она оказалась возможной (осуществимой) и даже удобной в практически качественном отношении. У продукта явно есть ЦА (сужу по активности request/issue пулов на MS гитхаб).

oOoOo ()
Ответ на: комментарий от mord0d

Судя по скрину на github, это все те же два окна в одном plain в другом рендер. Я тогда и в vi (да что там, прямо в консоли до EOF) могу сие осуществлять просматривая в браузере по автоапдейту…

oOoOo ()
Ответ на: комментарий от Pravorskyi

снова два окна с preview

В это может что угодно, для этого даже приложения специального не надо.

не развивается

Об этом я и говорю, нормальные текстовые редакторы десятилетиями развиваются, мне в эту сторону.

oOoOo ()
Последнее исправление: oOoOo (всего исправлений: 1)
Ответ на: комментарий от EXL

абсолютно читаем

Самый простой пример. Заголовки. Положим есть документ с достаточно сложной иерархически-подобной структурой. Он еще и не 10 строчек (как на github обычно) а полноценно объемный, документация. Вот как быстро ваш глаз подметит заголовок третьего уровня выделенный жирным на рендере, и насколько вдумчиво нужно вчитываться в plain/text ?

В этом и разница, я планирую использовать md максимально, насколько это возможно в моей ситуации, вы же ограничиваетесь описанием на гитхаб.

В прочем, что спорить, ситуацию это никоим образом не изменит.

oOoOo ()
Ответ на: комментарий от oOoOo

это все те же два окна

Ты хочешь WYSIWYG? M↓ был придуман не для этого.

Если тебе нужен WYSIWYG, то используй RTF, например. Или doc/docx/odf.

mord0d ★★★★ ()
Ответ на: комментарий от mord0d

Я бы с радостью их использовал если бы это не были бинарные форматы. Попробуйте их почитать без офисного пакета.

не для этого

А для чего ? Мне видилось что это rich-text с простым, не отвлекающим глаз синтаксисом. Как из этого следует то что процесс его использования не может быть приятным и удобным ?

Странно, помимо пары кривых поделок никто даже тот же emacs не посоветовал, хотя на yt есть примеры рендера в сплит-окне, при том что это реальный текстовый редактор а не блокнот с браузером. Вот только я расчитывал на typora-like вариант в решении такого же уровня.

oOoOo ()
Ответ на: комментарий от oOoOo

А для чего ?

Для того же, что и StructuredText, ReStructuredText и прочие — читабельный текст с не отвлекающей разметкой. Не WYSIWYG.

Мне видилось что это rich-text с простым, не отвлекающим глаз синтаксисом.

Нет.

Как из этого следует то что процесс его использования не может быть приятным и удобным ?

WYSIWYG требует либо очень хитрого парсера, либо чего-то типа XML (чем, если мне не изменяет память, является RTF). А значит исходный текст (не отрендеренный) становится нечитаемым.

Странно, помимо пары кривых поделок никто даже тот же emacs не посоветовал, хотя на yt есть примеры рендера в сплит-окне, при том что это реальный текстовый редактор а не блокнот с браузером. Вот только я расчитывал на typora-like вариант в решении такого же уровня.

Я использую Vim и не использую рендер Markdown. Посоветовал то, что недавно видел и даже немного тыкал.

mord0d ★★★★ ()
Последнее исправление: mord0d (всего исправлений: 1)
Ответ на: комментарий от mord0d

требуется очень хитрый парсер

Чтобы отловить установленный алфавит символов синтаксиса ? С четко формализованными правилами ? Что там парсить, я через sed в 20 строк половину синтаксиса могу реализовать… Я не вижу даже проблемы сделать это на JS или на чистом Си, вот только это будет очередной md редактор а не полноценный инструмент. Что - то типа emacs я конечно разработать не смогу.

Xml, html, rtf

Md в основе своей те же теги, только с отброшенной ненужной функциональностью и упрошенным обозночением таковых. Он ничем не отличается, разве что для указанных форматов соизволили нормальный визуальный редактор сделать.

нет

Мне казалось я описал фактическое положение дел, md > plain/text, следственно, rich, а синтаксис упрошен, дефакто.

oOoOo ()

Мне лень читать, что ты там написал, но вроде бы тебе надо typora.

Im_not_a_robot ★★★★★ ()
Ответ на: комментарий от Difrex

Дельный пинок на самом деле, спасибо. Ранее мне представлялось что это kind of to do (насколько же эта сентенция замыленная в использовании, аж передергивает) list плагин, наверное в заблуждение несколько ввел нейминг. Это конечно уже не так читаемо (скорее вообще не читаемо, что - то типа xml) в plain/text, однако, решение довольно фундаментальное, built-in в не менее фундаментальном текстовом процессоре, в перспективе развития и поддержке которого сомневаться не приходиться.

Пробежался по goolag выдаче, похоже многое что там реализованно (особенно в части органайзера) у меня сделано средствами md и логики файловой структуры, те же категории, разбиение и тд, та же иерархия только в профиль. Но я обязательно присмотрюсь, так как ждать у моря погоды с идеалистическими запросами можно долго, а использовать нужно как можно раньче, возможно удастся утенка/привычку побороть и обрести таки покой по этому вопросу.

oOoOo ()
Ответ на: комментарий от mord0d

WYSIWYG - это способ отображения, а не ограничение способа ввода.

Например, при использовании LyX для ввода TeX-формул - наиболее удобно их вводить набирая TeX-код, нажимая кнопки клавиатуры полностью идентично тому как это делается при написании TeX исходника. А LyX его мгновенно визуализирует. И видно в каком месте формулы сейчас печатаешь - не нужно считать сколько скобок уже закрыл, а сколько ещё нет!

Для Markdown нужно что-то такое же. Редактируешь исходник, только все управляющие симолы засерены как управляющие и все форматирования, включая размеры - отображаются налету.

Типа того как сейчас редактор github выделяет курсив и жирность, но только для всех элементов оформления, а не с ограничением для тех элементов оформдения которые вписываются в редактор с фиксированным размером шрифта.

GPFault ★★ ()
Ответ на: комментарий от oOoOo

Md в основе своей те же теги

Нет, там как в mdoc.

Он ничем не отличается

Не надо выдавать желаемое за действительное.

Мне казалось

Мне видилось

Кажется, пора принять таблетки от галлюцинаций. ☺

mord0d ★★★★ ()
Ответ на: комментарий от GPFault

WYSIWYG - это способ отображения, а не ограничение способа ввода.

Да, но это отражается на синтаксисе под капотом.

TeX-код

Ну, TeX — довольно сложный технически. M↓ же в сравнении с — примитивен.

Для Markdown нужно что-то такое же.

Технически это реализуемо, но смысла в этом нет — Markdown достаточно человекочитаемый, чтобы обойтись без этого. Повторюсь, что как и RST, Markdown разрабатывался с целью быть читаемым как есть.

Ну и плюс ко всему рендер M↓ в HTML позволяет стилизовать результат как хочется, а не в единственном виде, как, например, mdoc или ROFF.

mord0d ★★★★ ()

MacDown и не говорите, что для линукса такое ещё не нарисовали.

beastie ★★★★★ ()
Ответ на: комментарий от mord0d

нет

Почему же нет. Вот, например, < i >text< / i > в html, будет звездочкаtextзвездочка в md, обнаруживается сходство, видно упрощение как конструкции форматирования в целом, так и алфавита его реализации (звездочки в различном количестве, вместо < b > / < i > / < u l > / < li > и т.д).

как в mdoc

Разве что вывод хидеров, остальные теги требуют закрытия, также md не распологает ограниченным количеством полей, теги универсальны в этом отношении, более того – рекурсивны.

выдавать желаемое

Я пытаюсь разглядеть аргументативную форму вашей позиции более предметно, не имея мотивации (желаний), кои вы за меня декларируете.

таблетки

Их выдают по расписанию, с утра прием уже был. Правда, я их действительно не пил, товарищу по палате в блюдце отправил.

oOoOo ()
Ответ на: комментарий от oOoOo

Почему же нет.

Я уже выше писал про ===-/----хединги.

видно упрощение как конструкции форматирования в целом

Что усложняет парсинг.

остальные теги требуют закрытия

А как же листинги (прибитые к инденту)?

более того – рекурсивны

Сильно зависит от реализации парсера. Некоторые (в основном старые) реализации сильно хромают. И хромают больше не в плане рекурсии, а в отключении этой рекурсии где она не нужна (блоки кода, например).

mord0d ★★★★ ()
Ответ на: комментарий от oOoOo

3 * offtopic

у вас плохо получилось донести мысль, чего вы, собственно, хотите

next_time ★★★★★ ()

Есть org-mode для Emacs, но это почти что вендор лок, если хочешь удобно редактировать то сделать это можно только в этом редакторе.

Как уже тут написали, что редакторы с предпросмотром в отдельном окне хватает для большинства задач, иначе надо выбирать другой формат, markdown достаточно примитивен и для этой задачи, может больше подойдёт LaTeX.

Из редакторов с отдельным окном предпросмотра и созданием нескольких файлов заметок мне понравился QOwnNotes, программа с открытым исходным кодом и мултиплатформенная, умеет работать с каталогом заметок, который можно синхронизировать между системами через службы синхронизации файлов.

kodx ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)