Уменьшение числа файлов вообще и для Markdown в частности.

[ghost]

Я давно жду, когда появится замена для Zim, но с поддержкой Markdown :) OutWiker очень близкий кандидат, но у него есть несколько особенностей, не позволяющих пока на него перейти. Главное — это сильная «многофайловость» базы. Хочется иметь простую древовидную структуру без мусора, дабы можно было работать легко как из приложений, так и в файловой системе. Сейчас при создании страницы с использованием Markdown создаются:

__page.text

Тут всё понятно, Markdown как Markdown :)

__page.opt

Избыточный файл. Markdown прекрасно умеет мета-теги в начале файла. Обычно это делается тройными минусами перед и после блока данных в YAML-формате (или JSON, как подмножестве YAML):

---
order: 0
creationdatetime: 2017-05-25 08:29:19.596000
datetime: 2017-05-25 08:29:46.574000
tags: {"markdown","документы","outwiker"}
---

# Заметки об использовании Markdown в Outwiker
...

Этот формат прекрасно понимает и сам GitHub, кстати. Например: https://github.com/Balancer/airbase-static/blob/master/webroot/vehicles/m/mi-8ppa/index.md (Date/Author/Tags в шапке страницы). И, вот, в синтаксической подсветке выше этот фрагмент подсветился корректно :)

__icon.png

Имеет смысл только для нестандартных иконок. Если иконка стандартная, зачем её помещать в каждый каталог?

__content.html

Markdown прекрасно и быстро парсится на лету. Кеширование в виде .html явно избыточно.

То есть в результате для Markdown-базы заметок достаточно иметь только по одному файлу на страницу! При чём в отсутствии дочерних страниц можно хранить его не в подкаталоге, а в каталоге родительской страницы — тогда ещё и количество каталогов в разы уменьшится. Всё будет просто, наглядно, чисто.

Есть шансы, что такой подход будет реализован? :)

[ghost]

Вообще, для иллюстрации, как я предпочитаю использовать Markdown в дереве для организации базы:

• https://github.com/Balancer/airbase-static/tree/master/webroot
• https://github.com/Balancer/balancer-static/tree/master/webroot

Сейчас вся работа с такими базами осуществляется вручную. Но их идеология прекрасно ложится на подход OutWiker. Так что было бы замечательно, если бы OutWiker стал понимать подобный подход (не обязательно буквально :) )

Аналогичную структуру имеют также базы в CMS Grav. Хотя там несколько сложнее из-за использования цифрового порядкового номера для сортировки в именах корневых каталогов и есть некоторая нелогичность с учётом относительных ссылок на подстраницы. Но общая логика такая же, включая метатеги в заголовке Markown.

[Jenyay]

Как минимум __icon.png для нестандартных иконок я собираюсь убрать. Есть еще идея хранить иконку в виде base64 в __page.opt (но это на уровне идеи, боюсь, что из-за этого просядет скорость).

Сейчас __page.opt - самый главный файл, именно он определяет тип страницы и все параметры. По поводу файла __content.html надо подумать. Изначально он создавался, чтобы можно было бы смотреть отрендеренную заметку без запуска OutWiker. Но я не уверен, что этим кто-то пользуется.

PS. На самом деле в будущем может появиться еще один файл наподобие __page.opt, который должен содержать некоторые параметры из __page.opt, но которые не страшно потерять (например, контрольную сумму, положение курсора и т.п.) Это сделано для того, чтобы этот файл можно было бы добавить в .gitignore, и если база будет храниться в git, то меньше потребуется обновлений.

[ghost]

Есть еще идея хранить иконку в виде base64 в __page.opt (но это на уровне идеи, боюсь, что из-за этого просядет скорость).

У меня мелькнула такая мысль на тему мета-тегов в Markdown, но я подумал, что нет смысла замусоривать файл :)

Сейчас __page.opt - самый главный файл, именно он определяет тип страницы и все параметры.

Учитывая, насколько сегодня Markdown стал «де-фактическим» стандартом подобной документации, можно бы было сделать эдакое дублирование — если есть __page.opt — читать данные из него. Если есть, скажем, index.md — то из него. При чём не только метаданные, но и сам текст :)

файл наподобие __page.opt, который должен содержать некоторые параметры из __page.opt, но которые не страшно потерять

ИМХО, такое можно/нужно хранить уже не в дереве файлов/данных, а где-то в программе у себя. Тогда и .gitignore не понадобится.

[Jenyay]

ИМХО, такое можно/нужно хранить уже не в дереве файлов/данных, а где-то в программе у себя. Тогда и .gitignore не понадобится.

Может быть это будет вообще отдельный файл один на всю базу в корневой заметке.