История изменений

Acme — это текстовый редактор, в котором можно выделить любой текст и исполнить как команду. Интерфейс оптимизирован под эту задачу, что позволяет использовать Acme как замену эмулятора терминала и IDE.

Поскольку любой срез текста может являться командой, то история команд становится не нужна — необходимые команды можно записать в файл и исполнять их прям оттуда. История может захламиться, быть неудобной в некоторых задачах, требовать конфигурирования, быть несовместимой между разными шеллами, а список команд — это как личный cheat sheet, который сам выполняет действия и легко адаптируется.

Необходимость в автодополнении также пропадает, ведь команды редко приходится вводить заново. У меня сохранены сотни SQL-запросов, которые я исполняю без всякого автодополнения и зачастую без скриптов.

Прочие интерактивные помощники вроде пейджера или fzf становятся не нужны. Им нет места в текстовом редакторе, ровно как и в Acme.

Вывод любой команды можно сразу удалить. Или изменить. Или выделить и направить в другую команду. Или одной командой можно сгенерировать другую, вырезать и исполнить в другой директории.

Я годами не запускаю традиционный эмулятор терминала. Об этом подробнее здесь и здесь. (Иногда бывает нужен традиционный ввод команд, где командой может быть только последняя строка. Это реализовано как подмножество Acme, которое через API скрещивает обычное текстовое окно с шеллом.)

Многие работают с командной строкой на постоянной основе. Но как далеко на ней можно уехать? Можно ли запускать SQL-запросы? Можно, ведь это естественная задача шелла. Но неудобно. А в Acme удобно. Можно ли выполнять поиск по проекту через grep? Можно, ведь это буквально его задача. Но неудобно. А в Acme удобно. Можно ли выборочно убивать процессы через ps и kill (или удалить docker-контейнер по хэшу)? Можно, но только в Acme удобно. Можно ли сделать поиск и замену по файлу через sed? Можно, но только в Acme удобно. Можно ли после git status не вводить повторно длинный путь к файлу, чтобы сделать ему git add? Можно, но только в Acme.

Шелл является окном во все остальные текстовые интерфейсы. Но сегодня сам шелл чувствуется скорее как язык программирования (особенно из-за нагромождений GNU/bash), а не как интерфейс. Когда пользователю командой строки нужен интерфейс, он ищет интерфейс: отдельный клиент для каждой базы данных, для управления музыкой, процессами, гитом. А если ему придется использовать командную строку, то он не использует её как есть, а всячески обогащает: усложняет промпт, добавляет кучу алиасов, псевдографику.

В Acme шелл применим практически в любой задаче. Я, например, даже отступы выравниваю двумя скриптами на шелле.

Acme выполняет функцию IDE, собирая все инструменты в одном месте и предлагая единообразность в обращении с ними. Вопреки современным IDE, основанным на тесной связи с языком программирования и наличием встроенных батареек, Acme полагается на внешние инструменты, ничего не накапливая в себе, за что его иногда называют “integrating development environment.”

Иногда чистого шелла недостаточно для решения некоторых проблем. Например, переход к определению символа, открытие текущей позиции в GitHub, просмотр (текстовых) слайдов или /bin/cal в роли интерфейса ежедневника. Эти задачи решаются написанием внешних программ, которые знают об Acme только ≈10 файлов API, описание которых умещается две страницы мануала. Таким образом в Acme интегрирован LSP через внешнюю программу на Go.

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

Сегодня клавиатурное управление считается сложнейшим и наиболее эффективным методом управления, тогда как в Acme клавиатура используется только по прямому назначению — для ввода текста, а для управления используется исключительно мышь. Даже VS Code и продукты JetBrains слишком сильно зависят от клавиатуры в сравнении с Acme. Многим сложно поверить, что мышь может быть одновременно простой и эффективной, но я в это верю после опыта работы с vi/tmux/i3/dwm. Я увидел смысл в отказе от клавиатурного управления даже после многолетнего опыта — клавиатура требует придумывать, конфигурировать и привыкать к новым сочетаниям по мере возникновения новых задач и устаревания старых, что в работе программиста случается постоянно. В моём случае отказ от клавиатуры не повлёк за собой никаких штрафов и я стараюсь от неё избавиться везде, где это возможно.

В Acme очень дешёвые окна. Они постоянно создаются, меняют размер, позицию, временно всплывают и тут же удаляются, сортируются — и это происходит бессознательно, как управление машиной.

Acme — это текстовый редактор, в котором можно выделить любой текст и исполнить как команду. Интерфейс оптимизирован под эту задачу, что позволяет использовать Acme как замену эмулятора терминала и IDE.

Поскольку любой срез текста может являться командой, то история команд становится не нужна — необходимые команды можно записать в файл и исполнять их прям оттуда. История может захламиться, быть неудобной в некоторых задачах, требовать конфигурирования, быть несовместимой между разными шеллами, а список команд — это как личный cheat sheet, который сам выполняет действия и легко адаптируется.

Необходимость в автодополнении также пропадает, ведь команды редко приходится вводить заново. У меня сохранены сотни SQL-запросов, которые я исполняю без всякого автодополнения и зачастую без скриптов.

Прочие интерактивные помощники вроде пейджера или fzf становятся не нужны. Им нет места в текстовом редакторе, ровно как и в Acme.

Вывод любой команды можно сразу удалить. Или изменить. Или выделить и направить в другую команду. Или одной командой можно сгенерировать другую, вырезать и исполнить в другой директории.

Я годами не запускаю традиционный эмулятор терминала. Об этом подробнее здесь и здесь. (Иногда бывает нужен традиционный ввод команд, где командой может быть только последняя строка. Это реализовано как подмножество Acme, которое через API скрещивает обычное текстовое окно с шеллом.)

Многие работают с командной строкой на постоянной основе. Но как далеко на ней можно уехать? Можно ли запускать SQL-запросы? Можно, ведь это естественная задача шелла. Но неудобно. А в Acme удобно. Можно ли выполнять поиск по проекту через grep? Можно, ведь это буквально его задача. Но неудобно. А в Acme удобно. Можно ли выборочно убивать процессы через ps и kill (или удалить docker-контейнер по хэшу)? Можно, но только в Acme удобно. Можно ли сделать поиск и замену по файлу через sed? Можно, но только в Acme удобно. Можно ли после git status не вводить повторно длинный путь к файлу, чтобы сделать ему git add? Можно, но только в Acme.

Шелл является окном во все остальные текстовые интерфейсы. Но сегодня сам шелл чувствуется скорее как язык программирования (особенно из-за нагромождений GNU/bash), а не как интерфейс. Когда пользователю командой строки нужен интерфейс, он ищет интерфейс: отдельный клиент для каждой базы данных, для управления музыкой, процессами, гитом. А если ему придется использовать командную строку, то он не использует её как есть, а всячески обогащает: усложняет промпт, добавляет кучу алиасов, псевдографику.

В Acme шелл применим практически в любой задаче. Я, например, даже отступы выравниваю двумя скриптами на шелле.

Acme выполняет функцию IDE, собирая все инструменты в одном месте и предлагая единообразность в обращении с ними. Вопреки современным IDE, основанным на тесной связи с языком программирования и наличием встроенных батареек, Acme полагается на внешние инструменты, ничего не накапливая в себе, за что его иногда называют “integrating development environment.”

Иногда чистого шелла недостаточно для решения некоторых проблем. Например, переход к определению символа, открытие текущей позиции в GitHub, просмотр (текстовых) слайдов или /bin/cal в роли интерфейса ежедневника. Эти задачи решаются написанием внешних программ, которые знают об Acme только ≈10 файлов API, описание которых умещается две страницы мануала. Таким образом в Acme интегрирован LSP через внешнюю программу на Go.

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

Сегодня клавиатурное управление считается сложнейшим и наиболее эффективным методом управления, тогда как в Acme она используется только по прямому назначению — для ввода текста, а для управления используется исключительно мышь. Даже VS Code и продукты JetBrains слишком сильно зависят от клавиатуры в сравнении с Acme. Многим сложно поверить, что мышь может быть одновременно простой и эффективной, но я в это верю после опыта работы с vi/tmux/i3/dwm. Я увидел смысл в отказе от клавиатурного управления даже после многолетнего опыта — клавиатура требует придумывать, конфигурировать и привыкать к новым сочетаниям по мере возникновения новых задач и устаревания старых, что в работе программиста случается постоянно. В моём случае отказ от клавиатуры не повлёк за собой никаких штрафов и я стараюсь от неё избавиться везде, где это возможно.

В Acme очень дешёвые окна. Они постоянно создаются, меняют размер, позицию, временно всплывают и тут же удаляются, сортируются — и это происходит бессознательно, как управление машиной.

Acme — это текстовый редактор, в котором можно выделить любой текст и исполнить как команду. Интерфейс оптимизирован под эту задачу, что позволяет использовать Acme как замену эмулятора терминала и IDE.

Поскольку любой срез текста может являться командой, то история команд становится не нужна — необходимые команды можно записать в файл и исполнять их прям оттуда. История может захламиться, быть неудобной в некоторых задачах, требовать конфигурирования, быть несовместимой между разными шеллами, а список команд — это как личный cheat sheet, который сам выполняет действия и легко адаптируется.

Необходимость в автодополнении также пропадает, ведь команды редко приходится вводить заново. У меня сохранены сотни SQL-запросов, которые я исполняю без всякого автодополнения и зачастую без скриптов.

Прочие интерактивные помощники вроде пейджера или fzf становятся не нужны. Им нет места в текстовом редакторе, ровно как и в Acme.

Вывод любой команды можно сразу удалить. Или изменить. Или выделить и направить в другую команду. Или одной командой можно сгенерировать другую, вырезать и исполнить в другой директории.

Я годами не запускаю традиционный эмулятор терминала. Об этом подробнее здесь и здесь. (Иногда бывает нужен традиционный ввод команд, где командой может быть только последняя строка. Это реализовано как подмножество Acme, которое через API скрещивает обычное текстовое окно с шеллом.)

Многие работают с командной строкой на постоянной основе. Но как далеко на ней можно уехать? Можно ли запускать SQL-запросы? Можно, ведь это естественная задача шелла. Но неудобно. А в Acme удобно. Можно ли выполнять поиск по проекту через grep? Можно, ведь это буквально его задача. Но неудобно. А в Acme удобно. Можно ли выборочно убивать процессы через ps и kill (или удалить docker-контейнер по хэшу)? Можно, но только в Acme удобно. Можно ли сделать поиск и замену по файлу через sed? Можно, но только в Acme удобно. Можно ли после git status не вводить повторно длинный путь к файлу, чтобы сделать ему git add? Можно, но только в Acme.

Шелл является окном во все остальные текстовые интерфейсы. Но сегодня сам шелл чувствуется скорее как язык программирования (особенно из-за нагромождений GNU/bash), а не как интерфейс. Когда пользователю командой строки нужен интерфейс, он ищет интерфейс: отдельный клиент для каждой базы данных, для управления музыкой, процессами, гитом. А если ему придется использовать командную строку, то он не использует её как есть, а всячески обогащает: усложняет промпт, добавляет кучу алиасов, псевдографику.

В Acme шелл применим практически в любой задаче. Я, например, даже отступы выравниваю двумя скриптами на шелле.

Acme выполняет функцию IDE, собирая все инструменты в одном месте и предлагая единообразность в обращении с ними. Вопреки современным IDE, основанным на тесной связи с языком программирования и наличием встроенных батареек, Acme полагается на внешние инструменты, ничего не накапливая в себе, за что его иногда называют “integrating development environment.”

Иногда чистого шелла недостаточно для решения некоторых проблем. Например, переход к определению символа, открытие текущей позиции в GitHub, просмотр (текстовых) слайдов или /bin/cal в роли интерфейса ежедневника. Эти задачи решаются написанием внешних программ, которые знают об Acme только ≈10 файлов API, описание которых умещается две страницы мануала. Таким образом в Acme интегрирован LSP через внешнюю программу на Go.

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

Сегодня клавиатурное управление считается сложнейшим и наиболее эффективным методом управления, тогда как в Acme она используется только по прямому назначению — для ввода текста, а для управления используется исключительно мышь. Даже VS Code и продукты JetBrains слишком сильно зависят от клавиатуры в сравнении с Acme. Многим сложно поверить, что мышь может быть одновременно простой и эффективной, но я в это верю после опыта работы с vi/tmux/i3/dwm. Я увидел смысл в отказе от клавиатурного управления даже после многолетнего опыта — клавиатура требует придумывать, конфигурировать и привыкать к новым сочетаниям по мере возникновения новых задач и устаревания старых, что в работе программиста случается постоянно. В моём случае отказ от клавиатуры не повлёк за собой никаких штрафов и я стараюсь от неё избавиться везде, где это возможно.

В Acme очень дешёвые окна. Они постоянно создаются, меняют размер, позицию, временно всплывают и тут же удаляются, сортируются — и это происходит бессознательно, как управление машиной.