Acme/Sam?

Я ничего не понял.

Еще раз, но понятным языком.

А что ты сделал что за цифры?

vscode :(

acme это реально

acme site:usesthis.com

me gustó 5 из

Раз уж вы любите ИИ, попросите его переписать ваш вопрос в понятной человекам форме (а заодно и ответить на него самостоятельно, нас-то зачем мучать?).

Кто пользуется? Какие плюшки? Как реализуете в работе?

kaldeon

ничего не понял

Это для гуманоидов из далёкого космоса.

ничего не понял

Это для гуманоидов из далёкого космоса.

Рептилойдов же.

пропарсил сайт на дистры, ЯП и редакторы от маститых и не очень.
Оказалось, что все выходцы из Bell Labs и пару новых используют Acme.

Вот и задался вопросом.

РептилоИдов же!

эээ acme site:url

токмо 5 - кинь спискоту pls:

https://www.markdownpaste.com/document/7987de

Ну вот ты и спалился, рептилойд! (%

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 очень дешёвые окна. Они постоянно создаются, меняют размер, позицию, временно всплывают и тут же удаляются, сортируются — и это происходит бессознательно, как управление машиной.

Sam использую в командном режиме как замену sed и не представляю свою жизнь без него. В sam минимальной единицей обработки является не строка, а любой слайс текста. Это не только позволяет решать более сложные задачи, но и упрощает большинство задач.

Как, например, в sed заменить пробелы на табы? Я не гуру sed и, возможно, какой-то способ есть (ведь sed Тьюринг-полон), только для решения этой проблемы сделали отдельные инструменты /bin/expand и /bin/unexpand, тогда как в sam это тривильно: x/^ */ x/ / c/ /. Не в Тьюринг-полноте сила.

Или как заменить имя переменной a на account, при этом не трогая merchant? x/[a-zA-Z_0-9]*/ g/a/ v/../ c/account/.

Ещё sam полезен, когда хочется по определённому шаблону отредактировать десяток или сотню файлов, с возможностью делать это в несколько этапов, с отменами и просмотром изменений.

Учитывая тесную связь Acme и шелла, есть смысл рассмотреть rc. 16 страниц — всё, что нужно знать о rc, чтобы пользоваться им. Это в сотни раз меньше, чем мануал баша, и удобнее, чем Bourne/POSIX shell.

Тебе надо развёрнутую статью про Acme на ЛОРе написать, с упором на практические фишки, а не про то что он «просто другой» как часто его описывают. Глядишь и адептов новых приманишь.

Acme:

• https://usesthis.com/interviews/rob.pike/
• https://usesthis.com/interviews/russ.cox/
• https://usesthis.com/interviews/marius.eriksen/

Ещё Igor Böhm пользуется среди известных личностей. Деннис Ритчи пользовался.

Sam:

• https://usesthis.com/interviews/brian.kernighan/
• https://usesthis.com/interviews/gerard.holzmann/

Много материала, большой масштаб, поэтому тяжело справиться. Но однажды (не скоро) момент выхода в паблик наступит, а пока что готовлю сырой материал.

тоже жду. А есть видео работы? В youtube?

спасибо, нормально инфы. Особенно Игоря ссылки понравились.

это текстовый редактор, в котором можно выделить любой текст и исполнить как команду

Это в любом редакторе тривиально делается. (Конечно, имею в виду не редактор уровня Блокнота, а полноценный.) В чем киллер фича-то?

что позволяет использовать Acme как замену эмулятора терминала и IDE.

Исполнение написанных команд никак не делает редактор заменой эмулятора терминала и IDE. Вообще.

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

Ага, оч «удобно» вручную записывать команды в файл, а потом вручную же искать их там. История команд хороша именно тем, что она берёт на себя рутину по запоминанию и хранению команд.

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

Это такой кринж, что даже не вижу смысла комментировать.

Необходимость в автодополнении также пропадает, ведь команды редко приходится вводить заново.

А где команды «часто приходится вводить заново»? В command.com под DOS-ом? Потому что любой современный шел имеет историю команд с удобной навигацией и поиском. И любую нетривиальную команду никогда не приходится вводить заново.

Так мало того, смысл и суть автодополнения полностью упущены. Я пишу docker, нажимаю Tab, получаю мини-справку по его командам и понимаю, что писать дальше. Что мне может предложить Acme?

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

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

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

Да нет, это именно что удобно делать в оболочке. А в редакторе - не удобно.

Можно ли после git status не вводить повторно длинный путь к файлу, чтобы сделать ему git add? Можно, но только в Acme.

Непонятный кейс. Долго думал, что имеется в виду, но так и не понял, какое преимущество тут планировалось показать. Что там текст, что тут текст.

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

Ну а я строки сортирую внутри редактора командой на sh. В чем особый пафос-то? Обычная автоматизация приложений через возможность добавлять пользовательскую логику.

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

Это полный пиндец.

Мышь нужна чтобы в графическом редакторе фотки ретушировать и в компьютерные игры играть. Ну и чтобы в браузере на ссылки нажимать.

Я работая по основной своей работе, могу за час работы вообще мыши ни разу не коснуться.

Я увидел смысл в отказе от клавиатурного управления даже после многолетнего опыта — клавиатура требует придумывать, конфигурировать и привыкать к новым сочетаниям по мере возникновения новых задач и устаревания старых, что в работе программиста случается постоянно.

Это потому что ты не освоил в полной мере самый можный принцип взаимодействия с машиной - отдачи текстовых команд. Поэтому пытался какие-то хоткеи изобретать.

Хоткеи должны быть максимально базовыми и максимально мощными. Они должны быть такими, чтобы максимально человека приблизить к отдаче машине текстовых команд, упростить эту задачу максимально.

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

Самое лучшее видео работы записал Russ Cox.

как раз смотрю, спасибо

«Практические фишки»: не пользоваться хоткеями, мышью нажимать на команды для выполнения.

Тут бесполезно писать статью, пусть он запишет видео, как работает за машиной. Это же жесть.

Я использую Zed (игра слов от Z editor, что Z значит я не знаю, вообще Z и X америнцы любят) и Neovim.

vis - для пацанов, а остальное…

Для взрослых мужчин (ну и женщин тоже)?

Сначала ты учишь vim, потом Emacs, а затем наступает просветление.

Как, например, в sed заменить пробелы на табы?

Элементарно же:

$ echo test test test | sed 's/ /\t/g'
test	test	test

тогда как в sam это тривильно: x/^ */ x/ / c/ /

Я бы не назвал это тривиальным.

Чувствую, это будет надолго. Ну что ж, поехали.

[выделить любой текст и исполнить как команду] в любом редакторе тривиально делается… В чем киллер фича-то?

В vi это делается через тривиальное :.w !sh. Вводим команду, чтобы запустить команду. Я в своё время это повесил на ^A^A и прочие модификации.

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

Исполнение написанных команд никак не дает редактор заменой эмулятора терминала и IDE.

Насчёт эмулятора терминала — не получится запустить htop, lazygit и прочую псевдографику. А обычные текстовые команды можно полностью перенести. Но да, мне стоило написать «заменить эмулятор терминала в качестве командного [а не псевдографического] интерфейса».

У IDE есть два смысла. Один — тесная интеграция с языком программирование и встроенные батарейки. Acme этого не может сделать. Второй смысл — сбор инструментов в одном месте. Это — может.

В общем, претензия валидная, надо быть точнее.

Ага, оч «удобно» вручную записывать команды в файл, а потом вручную же искать их там.

Хотите сказать, что работать с файлами и с текстом неудобно?

История команд хороша именно тем, что она берёт на себя рутину по запоминанию и хранению команд.

Она замусорится. Что-то будет не нужно, вместо одной команды будет 10 вариаций, половина будет с ошибкой.

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

(У меня была идея привязать историю к текущей директории, но времени подольше посидеть на таком — нет. Но могу сразу предвидеть, что тогда просто забудешь где именно была введена та самая команда.)

Можно сделать рейтинг команд — чем чаще используется, тем первее будет предлагаться. Неплохо, но не все шеллы это умеют делать, особенно всякие базы данных. И команда имеет ценность только в определённое время. Если я вернусь к задаче, над которой работал месяц назад, то мне и рейтинг нужно откатить на месяц.

Что насчёт запуска двух связанных команд, которые должны выполняться по порядку? Одну мы смогли кое-как найти в истории, а как найти вторую? В файле они будут стоять рядом.

А где команды «часто приходится вводить заново»?

vi /etc/mki^Ic^I. Если нужно повторно ввести эту команду и она не была предыдущей, то либо ↑↑↑↑↑↑↑…, либо поиск по истории будет эквивалентен повторному вводу. В Acme если я знаю, где последний раз видел /etc/mkinitcpio.conf, то найду это место довольно быстро.

Или, например, как ввести команду git log, чтобы она показала изменения от мастера до текущей ревизии? Нужно использовать две или три точки? А как сделать чтобы показывались только изменённые файлы? Я помню команду только приблизительно и поиск может затрудниться, тогда как в файле я сразу вижу “git log –name-only –oneline master..HEAD”.

Я пишу docker, нажимаю Tab, получаю мини-справку по его командам и понимаю, что писать дальше. Что мне может предложить Acme?

Для получения справки нужно написать man docker (или tldr — какой-нибудь ресурс, содержащий справку в желаемом формате), исполнить команду мышью, справка появится в новом окне, после чего можно дописать команду и перед исполнением вырезать “man”. При этом движение мышью будет минимальным: прыжок до нового окна и назад автоматизирован.

Связь автодополнения со справкой — кейс, кстати, неочевидный для меня. Я так не делал никогда.

А в чем пойнт-то?

Целью цитируемого отрывка было показать, насколько просто можно делать то, что делается непросто в эмуляторе терминала.

Моментальное удаление вывода команды — аналог ^L↑ в баше. Окей, не додумался.

Изменить вывод или направить в другую команду — периодически бывает полезно. Например, сделал я скриншот, мне программа написала “/home/kaldeon/screens/2025.10.05-1.png”. Я тут же её открыл, убедился, что всё норм, и дописываю в начало 0x0, исполняю и скриншот улетел на http://0x0.st.

… пользуюсь я [исполнением выделенного текста хоткеем] редко, потому что неудобно.

А я постоянно, потому что удобно.

Да нет, это именно что удобно делать в оболочке.

Удобно вводить SQL-запрос на несколько строк без возможности вернуться на предыдущую строку? В текстовом редакторе это тривиально. Мультилайн бесплатно, с предсказуемой копипастой (при вводе команды добавляется промпт на каждой линии), мелкие изменения не загрязняют историю.

Поинты про ps/kill и gitstatus/gitadd одинаковы. Мышь плохо подходит для копипасты, потому что чужеродна — когда всё оптимизировано под клавиатуру, тянуться к мыши неприятно и люди предпочтут более эффективный интерфейс (htop). Клавиатурная копипаста в tmux ужасна.

Про grep я, наверное, неточно выразился. Я имею ввиду использовать grep для любой задачи, связанной с поиском текста по проекту. Чаще всего эту задачу переносят на редактор кода. В Acme можно использовать grep.

Про sed — здесь vi справится, да, я уже забыл. Но это даже в vi удобно, а в эмуляторе терминала сделать замену в произвольном регионе — нет.

Ну а я строки сортирую внутри редактора сортирую командой на sh. В чем особый пафос-то?

В том, что строки приходится редко сортировать, а выравнивать отступы — постоянно. Пафос в том, что UI оптимизирован под эту задачу.

Мышь нужна чтобы в графическом редакторе фотки ретушировать

Клавиатура не имеет ничего общего с рулём, но позволяет играть в гонки. И это хорошо, потому что делает имеющиеся навыки полезными в решении новой задачи. Аналогично с мышью: хотя она подходит для редактирования фотографий, что плохого в том, чтобы применить эти навыки для другой задачи?

Хоткеи должны быть максимально базовыми и максимально мощными. Они должны быть такими, чтобы максимально человека приблизить к отдаче машине текстовых команд, упростить эту задачу максимально.

У меня одно время были такие хоткеи. ^A^A отдаёт текущую команду, ^A} — как } в vi, ^Ae — до EOF. Работало, но масштабировалось плохо — в vi это гражданин минус первого сорта. Поэтому приходилось, скажем, на #m вешать передачу текста как запрос в бд. То есть это не только я, может быть, не понял чего-то, а вообще большинство.

Большинство современных программ имеют не максимально-базовые и максимально-мощные хоткеи, а сотню хоткеев, из которых штук 50 выделяют в cheat sheet. Самый популярный адвокат клавиатурного управления — vi/vim — нарушает этот принцип во всю, усугубляя проблему плагинами, в которых каждый определяет свой собственный особой набор хоткеев.

Но ладно, оставим их ненадолго в стороне. Если говорить про отдачу текстовых команд машине, то почему эта задача должна обязательно решаться клавиатурой? Что неправильного в том, чтобы вместо трёх (в моём случае) хоткеев клавиатуры иметь один клик мыши? Я же печатаю постоянно, чтобы мне было сложно оторвать руку от клавиатуры.

Небольшая демка. Так у меня выглядит git-меню. Это обычные команды (gitadd — тонкая обёртка над git add), расположенные в удобном месте (в начале файла) рядом друг с другом. Мне за 2 года редкий раз приходилось вручную вводить с клавиатуры другие команды — как правило, когда что-либо ломалось. За весь день я мог ни разу не написать “git status” или “git add,” при этом сделав несколько MR.

а как тебе язык sam? Удобно? И почему? https://doc.cat-v.org/bell_labs/structural_regexps/

Я же печатаю постоянно, чтобы мне было сложно оторвать руку от клавиатуры.

s/постоянно/не &/

Acme/Sam? (комментарий)

Прошу прощения, я в описании задачи не упомянул, что нужно заменить пробелы на табы в отступах исходного кода. То есть в середине не надо менять.

“x” запускает цикл, “c” меняет фрагмент. Поэтому x/^ */ x/ / c/\t/ звучит как «сделай цикл по пробелам в начале каждой строки, в нём запусти цикл по четырём пробелам, каждые четыре пробела замени на таб».

Недавно на ЛОРе была задача по обработке текста. Вот решение на sam, sed, и awk:

• sed: замена определенных символов встречающихся до некоторого знака (комментарий)
• sed: замена определенных символов встречающихся до некоторого знака (комментарий)
• sed: замена определенных символов встречающихся до некоторого знака (комментарий)

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

Важное ограничение/особенность sam — изменения должны проходить по порядку без пересечений.

благодаря пламберу автовыбор чем интрепретировать универсально_активированный_текст

прст приведу пример недо асме в vscode # далее # реплики отсутствующие в клавиатурном вводе

code . w
#in w:
ls >>w
#автовыполним ctrl-shift-/ автовыбираюемую строку (по курсору без выделенного текста) текущим интерпретатором (который по ctrl-J али ctrl-`)
# ctrl-s  ## code -ой чой-то не то показать code -diff  "w памяти" "w диска"   ### агась

чиста для недо-примера как из иного инструмента получить нечто

где одно окно тектовый поток входных команд, а парное окно текстовый поток выхлопов

проще же обычно

вызов_с_тектовым_выхлопом | code . - 

прикол в том что в популярных (code в том числе) делается через россыпь трюков которые «вкушаемы» как микросервисы с бардаком в итоге - которого никто не хотел и по этому оно не избежно

в Acme (через sam очевидней) же нужно сначала перевалить некий пик_рая что бы оказаться в эльдорадо интерфейсов

Ага, оч «удобно» вручную записывать команды в файл, а потом вручную же искать их там. История команд хороша именно тем, что она берёт на себя рутину по запоминанию и хранению команд.

ты не в шелле - ты в области ввода

набрал «строку» - выполнил - автооктрылось окно выхлопа если искать grep по области_ввода области_вывода

сила слов а не картинок :)