Автор статьи автоматизировал рутинную задачу: вручную копировал GitHub issues в Org-файлы для отслеживания в Agenda. Делал он это годами, пока не решил: «Пора автоматизировать». В итоге за день он собрал инструмент с помощью Emacs, его пакетов и внешних утилит.
Исходные требования были просты: копировать issue (заголовок, описание, метаданные) как Org-задачу, работать преимущественно из Emacs, не лезть в браузер, писать комментарии в Org, создавать новые issue, открывать issue в браузере. При этом автор не хотел ставить полноценный GitHub-клиент, заморачиваться с синхронизацией между локальным и серверным состоянием и тратить больше дня.
Решение опиралось на готовый CLI gh, пакеты Transient и vtable для интерфейса, ox-gfm для конвертации Org в Markdown, Pandoc для обратной конвертации и встроенный парсер JSON в Elisp. Получившийся пакет fj состоит примерно из 400 строк кода. Ключевая функция fj-request-issues формирует команду для gh, запускает её через shell-command-to-string, парсит JSON в хеш-таблицу Elisp — и всё это меньше чем в 20 строках. Затем таблица отображается в vtable, и пользователь может перемещаться по issue, видя детали в соседнем окне.
Автор подчёркивает, что Emacs — среда для «ковкого» (malleable) программирования. Код можно написать и сразу выполнить, не перезапуская редактор. Разработка сводится к циклу «правишь — проверяешь», без длинной компиляции. Любые программы, доступные из оболочки, легко встраиваются. Это позволяет делать инструменты «для одного» (build for 1) — достаточно, чтобы работало лично у тебя. Проектирование для N пользователей требует тестов, документации, упаковки — на порядок больше работы. Но в ковком подходе это выбор, а не обязательство.
В итоге автор за полдня получил то, что хотел: из Emacs он просматривает issues, копирует их в Org, создаёт новые и открывает в браузере. Без запросов к разработчикам, без изучения чужого API — просто соединил элисповые пакеты и консольные утилиты.