[О блоге] [наверх] [пред] [2025-05-08 18:29:04+03:00] [ba169c2948c9d80fee2ad63a11fbe46a6a371b32]
Темы: [doc][keks][perl][vim][zsh]

Нет предела минимализму. Переписал zk.zsh на Perl, доку KEKS с Texinfo

http://www.git.stargrave.org/?p=zk.git;a=blob;f=zk
http://www.keks.cypherpunks.su/
Когда-то (b1ac320825bc6653f09ad75359b5a97fc1692f8c) я написал утилитку
на zsh, которая из текстовых файлов с [ссылками] доставала, собственно,
сам список ссылок и могла отвечать кто на кого ссылается. Плюс
преобразовывала их в HTML, позволяя в web-обозревателях просматривать,
кликая по []-ссылкам.

Почему бы не использовать это всё для документации к софту? Когда не
нужно кучу форматирования красивого. Например для KEKS проекта. Texinfo
мне нравится -- считаю лучшим форматом для документации. Но для простых
проектов нельзя бы что-то попроще, с куда меньшим порогом входа и
зависимых програм? zk.zsh как-раз подходит для этого, как мне кажется.
Для Texinfo есть только одна реализация. Info не так удобно смотреть без
info-обозревателя, которых тоже не много. Сам я в доку KEKS подглядываю
регулярно за криптографией, но оформление в Texinfo формате ничем не
помогает и бОльшая часть текста там в verbatim-блоке расположена.

Решил переписать на Perl. Так как zsh всё же не у всех людей из коробки
стоит, а Perl почти наверняка. Плюс он работает ощутимо быстрее и я не
реализовывал кэширование как это было в zsh реализации из-за много
мегабайтных текстовых файлов.

Не хватает в zk утилите поддержки обычных ссылок, не внутренних [].
Пытаться преобразовывать всё что похоже на URI -- высока вероятность
ошибок всяких. Пришёл в решению как в gemtext, gopher. Не, gemtext мне
не нравится, как и почти всё что связано с gemini-протоколом. Как
минимум из-за его использования длинных строк. Плюс он не может быть
заменой простейших HTML с изображениями. Никто не обязывает
автоматически подгружать img, но нужно уметь подсказывать обозревателю
разницу между изображениями и остальными ссылками. Но я согласен с тем,
что (как и в gopher) -- можно обойтись ссылками просто на отдельных
строках. Как минимум, это позволит облегчить парсинг и использовать
URI/URL любой сложности. Ссылки на изображения -- тем более легко смогут
прожить по отдельности на разных строчках.

Но меня всё равно напрягает вероятность ложного срабатывания на
каких-нибудь "=> URL" строках. Нужно же чтобы эти строчки были и
дружелюбными к человеку, чтобы он мог и без zk утилиты всё это клепать и
использовать. Решил поступить так: добавлять \r в конце. Не на 100%
уверен в том, что мне это нравится, но и контраргументов пока не могу
придумать хороших. Это на 100% избавляет от вероятности ложного
срабатывания: по сути все "\r\n" строчки автоматом сигнализируют о своей
особенности zk утилите. Если их просто вывести в терминале: то они
вообще визуально ничем не будут отличаться от "\n" нормальных.
Предполагаю, что в любом нормальном редакторе "\r" символ тоже будет
виден, выделяться, легко искаться. В vi(m) это так.

Возможность автоматического создания списка ссылок на страницу позволяет
создавать категории/каталоги/индексы. Типа динамический автоматический
создаваемый список.

Перевёл всю документацию (сайт) KEKS-а на этот новый формат. Просто
масса plaintext файлов. Причём, в отличии от Info, найти нужный
раздел/страницу можно просто открыв файл с её названием.

    [оставить комментарий]