Паттерн Editor-as-UI

Editor-as-UI - это Unix-паттерн, при котором текстовый редактор пользователя используется как интерфейс ввода для программы. Программа создаёт временный файл, открывает его в $EDITOR (или $VISUAL) и считывает результат после выхода из редактора.

Он занимает нишу между двумя более очевидными вариантами. Чистые флаги командной строки легко писать, но они быстро становятся неудобными с ростом числа параметров или длины ввода. Полноценный TUI (curses, Bubble Tea, ncurses) даёт настоящую интерактивность, но требует серьёзных инженерных затрат и создаёт ещё один интерфейс, к которому пользователю придётся привыкать. Editor-as-UI заполняет этот промежуток: пользователь остаётся в привычном редакторе - с моторной памятью, плагинами, историей отмен, поиском и вставкой, - а программа бесплатно получает этап ввода, эквивалентный тысячам строк UI-кода.

Как это работает

Механика во всех реализациях одинакова:

1. Создать временный файл (mktemp) или открыть файл настроек по фиксированному пути.
2. При необходимости заполнить его значениями по умолчанию, комментариями с описанием вариантов или данными прошлого запуска.
3. Запустить $EDITOR (с запасным вариантом в виде $VISUAL, а затем с жёстко заданным vi/nano на крайний случай), передав ему файл.
4. Дождаться завершения процесса редактора. Общепринятое соглашение о коде возврата: ноль означает применить, ненулевой код часто означает отмену.
5. Считать файл обратно, распарсить, проверить. При ошибке валидации классические реализации перезапускают редактор, добавив комментарий с ошибкой в начало файла (именно так работает crontab -e).

Канонические примеры

Существующие программы, использующие этот паттерн:

• git commit - пустое сообщение отменяет коммит; git rebase -i расширяет идею до структурированного DSL.
• crontab -e - повторно запускает редактор с ошибкой внутри файла, если синтаксис cron не удалось распарсить.
• visudo - блокирует /etc/sudoers на время редактирования и валидирует результат перед сохранением.
• vipw - то же самое для /etc/passwd. Man-страница буквально преподносит валидацию как главную возможность.
• gh pr create --editor и многие другие подкоманды gh.
• kubectl edit - применяет diff между исходным и отредактированным YAML.

Когда подходит

Подходит лучше всего:

• Входные данные имеют текстовую природу (конфигурация, запрос, сообщение, список).
• Набор параметров достаточно мал, чтобы поместиться на одном экране редактора, но слишком велик или неструктурирован для флагов командной строки.
• Пользователю полезно видеть комментарии, документацию и предыдущие значения прямо во время редактирования.
• Пользователь достаточно технически подкован, чтобы в $EDITOR у него уже был настроен любимый редактор.

Не подходит:

• Интерактивные процессы, требующие живой обратной связи (отслеживание изменений файлов, инкрементальный поиск при вводе).
• Нетекстовый ввод - выделение областей на изображениях, перемотка звука, перетаскивание элементов.
• Конечные пользователи не из среды разработчиков, у которых не задан $EDITOR или которые не знают, что такое vi.
• Задачи, которые должны быть встроены внутрь TUI другой программы.

Идиомы

Несколько приёмов, которые часто встречаются в качественных editor-as-UI скриптах:

• Комментарии как документация. Первой строкой временного файла часто идёт комментарий # со списком допустимых значений для поля ниже - как блок инструкций в git rebase -i или список доступных поддиректорий в обёртке над yt-dlp от Gauer'а.
• Сохранение состояния вместо mktemp. Файл настроек по фиксированному пути позволяет при втором вызове стартовать со значений первого. Расплата за это - потеря потокобезопасности при параллельном запуске, но для личных инструментов это обычно не критично.
• Проверка и повторное редактирование. При ошибке парсинга добавьте ошибку в виде комментария в начало файла и откройте редактор снова - не стоит просто завершать работу и терять введённые пользователем данные.
• Проверка diff'а. Если пользователь закрыл редактор, ничего не изменив, считайте это отменой.

Почему это сложно заменить

Собственный TUI-виджет текстового ввода, сопоставимый по возможностям с полноценным редактором, потребовал бы: перемещения курсора (по словам, строкам, абзацам), поиска, поиска с заменой, отмены/повтора с ветвлением, мультикурсора, подсветки синтаксиса, вставки из системного буфера обмена, настраиваемых комбинаций клавиш, поддержки нескольких буферов. Это годы работы. Editor-as-UI даёт всё это по цене вызова system().

Ближайший современный эквивалент - открытие файла в VS Code через URL handler или форма на Bubble Tea, но ни один из них не сравнится по универсальности: $EDITOR есть на каждой Unix-системе. Это несущая инфраструктура, которую никому не пришлось писать с нуля.

Связанные страницы

• text-editor-as-ui - пост Dave Gauer'а, в котором я впервые встретил название этого паттерна
• clean-code-coding-agents - та же идея опираться на существующий контекст вместо изобретения велосипеда, применённая к LLM-инструментам
• good-tools-are-invisible - версия той же мысли со стороны создателя инструментов от Ginger Bill'а: хороший инструмент уходит на задний план, а не требует к себе внимания
• sheets - отказывается от компромисса: полноценный TUI с привязками клавиш в стиле vim для просмотра CSV плюс CLI-режим без флагов (sheets budget.csv B7=10) для правок, которым интерфейс вообще не нужен