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

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

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

В 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.

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

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

В 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 справится, да, я уже забыл. Но это даже в vim удобно, а в эмуляторе терминала сделать замену в произвольном регионе — нет.

Ну а я строки сортирую внутри редактора сортирую командой на 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.

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

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

В 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 справится, да, я уже забыл. Но это даже в vim удобно, а в эмуляторе терминала сделать замену в произвольном регионе — нет.

Ну а я строки сортирую внутри редактора сортирую командой на 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.

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

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

В 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 справится, да, я уже забыл. Но это даже в vim удобно, а в эмуляторе терминала сделать замену в произвольном регионе — нет.

Ну а я строки сортирую внутри редактора сортирую командой на 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.