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 по области_ввода области_вывода

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

Вот некоторые мои хоткеи:

• Mod4+Q - Открыть новое окно терминала
• Mod4+W - Открыть текстовый редактор (ом мультивкладочный, с сохранением списка вкладок между перезапусками; всплывает уже существующее окно, есди уже запущено)
• Mod4+E - Открыть графический ФМ
• Mod4+R - Открыть промпт dmenu для выбора команды для запуска.
• Mod4+Tilda - Открыть промпт dmenu со списком открытых окон.
• Mod4+Shift+W - открыть выделенный текст как файл в текстовом редакторе
• Mod4+Insert - Открыть меню с историей буфера обмена X11.

Bash у меня настроен так, чтобы в заголовке терминала отображать:

• Если bash находится в режиме промпта: «user@host:working dir:prev command exit status:prev command»
• Если bash запустил команду и ждёт заверщения: отображается текст команды.

Если команда завершилась ненулевым статусом, то в промпт дописывается статус красным цветом и расшифровка сигнала:

vadim@aquila:~$  cat
^C
Status: 130[INT]
vadim@aquila:~$  false
Status: 1
vadim@aquila:~$ 

По хоткею Mod4+Shift+W происходит следующее. Если выделенный текст начинается со слеша, он трактуется как полный путь. Если с тильды - как путь в хомяке. В ином случае происходит следующее. Из названия активного окна извлекается имя существующего файла или каталога. Если это регулярный файл, то оно урезается до каталога. Затем относительно полученного каталога трактуется выделенный текст как имя файла.

Таким образом, если я в терминале вижу любой фрагмент, который является именем файла, я могу выделить его мышкой, нажать Mod4+Shift+W и открыть в текстовом редакторе.

Если в самом текстовом редакторе я вижу строку а ля #include "blabla.h", то я могу выделить blabla.h, и аналогично открыть файл. Не важно, существует он или нет, так можно и новые файлы создавать.

Это работает прозрачно с любым текстом где угодно.

Внутри самого редактора из интересных хоткев:

• Ctrl+E - выполнить выделенный текст как выражение Lua и намечатать результат на следующей строке. Очень удобный калькулятор получается.
• Ctrl+Shift+Backslash - выполнить выделенный текст как команду оболочки в каталоге текущего файла и вывести результат в этот же файл.

В редакторе можно добавлять любые кастомные команды на Lua или sh, они добавляются в меню Инструменты, и им можно назначать хоткеи. Код на Lua исполняется непосредственно внутри процесса редактора и имеет доступ к API для редактирования текста. Для кода на sh задаются настройки, что подавать на stdin скрипта и и что делать с его stdout.

Два примера выше точно так же сделаны как инструменты - это не часть логики самого редактора. Сам редактор отвечает только за запуск настроенных пользователем инструментов.

Таким образом возможно как угодно обрабатывать текст в текущем файле или запускать файлы в текущем каталоге.

Еще из таких инструментов, которыми я пользуюсь:

«Sort | Uniq»

sort | uniq

«Diff to Disk»

diff -pu "$DOC_PATH" "$INPUT_FILE" > "$TEMP_DIR/m.diff"
"$QK" -r "$TEMP_DIR/m.diff"

«Gitk - Directory History»

gitk "$DOC_DIR"

«Gitk - File History»

gitk "$DOC_PATH"

«Git GUI»

cd "$DOC_DIR" && git gui

«Git GUI - Blame»

git gui blame "$DOC_PATH"

«GitHub - Locate File» — скрипт проверяет, имеет ли репозиторий github-овский URL, и если да, открывает в браузере для текущего редактируемого файла его версию в гитхабовой репе.

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

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

Mod4+Q, " man docker", Enter

В Acme если я знаю, где последний раз видел /etc/mkinitcpio.conf, то найду это место довольно быстро.

Ctrl+R, «/mkin», Enter

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

hgrep git\ log - греп по истории команд, тривиальная функция в .bashrc

А еще в истории команд можно использовать отображаемые комменты. Не то что бы я этим пользовался, но может кому пригодится такая возможность:

git clean -dxf ; : dangerous

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

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

Если команда сильно нетривиальная, то открываем текстовый редактор и пишем скрипт.

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

tmux плохо подходит для моего workflow, поэтому я им не пользуюсь. Гораздо удобнее создавать новые окна терминала, а внутри окна можно создавать вкладки средствами приложения терминала.

Что мне сейчас не хватает в приложении терминала, это хоткеев «скопировать видимую часть буфера» и «скопировать весь буфер». Когда-нибудь я найду время добраться до его исходного кода.

http://0x0.st/KMlD.05-1.png

Я не понимаю, как люди пользуются немоноширинным шрифтом для работы с исходниками и командами.

Это какой-то особый склад ума, который был у авторов Sam, и который прослеживается у пользователей. И использование мыши для всего, и использование шрифта переменной ширины как-то у них уживаются вместе в голове в единую систему.

мало амбидекстеров

так то два указателя : текстовый_курсор + выбор_обьекта(указатель через :мышь, перо(света на элт),тачскин,тачкад,тачпоинт,трекболл)

субд это вариант os :)

и да дешёвые окна/табы ключь - та же vscode вполне тайловый менеджер окон(текста уникода раскрашенного)

основная проблема реальная - привычка досрочно разименовывать ссылки в значения - поэтому что «проводник» что «ortodox file manager» вместо инструмента помощи (как доп колёса на детских велах) оказыются production ready инструментами продвинутых ....

и да раскаска крута ибо colorforth - и вручную спроектированные сильноконкурентные процы :)

В X11 тоже было заложена работа с двумя точками интереса: PRIMARY selection и CLIPBOARD selection.

Но оказалось, что это не востребовано, потому что слишком перегружает мозг.

Вон на LOR некоторые вообще жалуются, что PRIMARY им жить мешает.