Acme подходит для любого проекта, работу с которым можно организовать используя текстовые команды. Поиск файлов/слов - grep, сборка проекта - make, git/docker - самоочевидно, работа с HTTP - curl, сторонние сервисы - mysql-client/redis-client/etc. Отличие от обычного эмулятора терминала в том, что Acme позволяет хранить команды в файлах.
Терминал, какой бы современный интерактивный шелл не использовался, неудобен, хотя все им умеют пользуются. В этом смысле Acme направляет имеющиеся скиллы в более продуктивное русло.
В Vim нет плагинов чтобы как-то приблизится к Emacs.
Но в этом концепция Vim, написание своих функций сочетающих стандартные возможности.
Emacs полностью расширяемая среда как эталон software architecture.
Раскин (мастер интерфейсов(пользовательских) первых Маков(недо лизы которые) показал своим изделием что могло бы быть идеальным инструментом текстованния в отсутствие закона Мура и фиатной накачки спроса бубенцами и свистелками
речь про тектовое взаимодействие acme/Oberon(среды) - где есть курсор текста и курсор мыши (либо их эмуляция одним курсором и моды)
ща в vscode:
* есть недо тайлинг как в acme
* исполнение выделенного произвольным шелом
?(нехватает) < | > ухватки ввода вывода замещения в самой среде
самой Acme (если бы б продолжал пользоваться то скорее Sam) - не взлетело ибо робинзонить без пятниц тяжко :(
зы:
частично есть получение вывода в «временый» файл если исполняемое выделение тем или иным способом осуществляет |code [path] - (в том же path али при его отсутсвии)
Использую в основном для работы над гошными проектами.
Практика, которую использую по сей день: сохраняю команды в файл, который игнорируется глобальными настройками гита. Обычно этот файл называют «guide».
Довольно долго держал файл $home/guide, через который открывал проекты. Там была примерно такая команда:
<find github.com -type f |sort |grep '/guide$'
В файле guide – команды. Последнее время я чаще всего я использую find, grep, git и psql.
Сперва выполняю команду find, которая даёт список всех файлов, затем на этом выделении один из двух grep-ов.
Можно использовать grep -R или ripgrep, но я стараюсь без необходимости не выходить за пределы возможностей, описанных в мануалах Plan 9. Эти мануалы хороши тем, что они хорошо подсвечивают традиции и нормы использования инструментов.
Пробелы и табы в названиях имён можно пофиксить через $ifs, но проще просто не париться об этом.
Когда я понял, что пользуюсь поиском очень часто и постоянно ходить в файл неудобно, создал скрипт Global, который создаёт окно с результатом «find . -type f |sort» и шаблоном grep в теге (заголовке) окна.
git – по-умолчанию просто держу команды, которые знаю, что выполняются регулярно.
Вместо git status использую git status –short –untracked-files. На это есть две причины. Первая – легко автоматизировать (|sed 's/^../git add/'). Вторая – можно тыкнуть на существующий файл, затем применить аккорд 2-1 к команде git add/checkout/reset. Работает как кнопка.
Чтобы дополнительно уменьшить количество кликов, я сделал скрипты gitadd/gitcheckout/gitreset. Без пробелов не нужно выделять всю команду.
По такому же принципу прыгаю по веткам и коммитам.
Нравится добавлять только часть изменений в индекс используя git apply. Но этому было трудно научиться. Обычно используют git add –patch. Поскольку это традиционный repl, его нужно запустить через win git add --patch, как и любой другой традиционный repl.
Для работы с бд также использую Acme. Команду для подключения оборачиваю в скрипт, в результате получая «кнопку». При необходимости можно переключиться на моноширинный шрифт через Font.
Как правило, файлы guide большие. Основное средство навигации – поиск. Есть два подхода. Первый – сделать Zerox окна и в теге написать команду для перехода к нужной позиции. Например, для перехода к командам гита я использую :0/^git/.
Есть похожий подход, который пригождается время от времени. Поисковые запросы можно держать в пустом окне. Когда нужно – выделяешь, затем применяешь аккордом 2-1 к команде Edit в окне, где этот поисковый запрос нужно осуществить.
(По этому же принципу работает команда Look, но она ищет обычные строки. Какое-то заранее известное назначение трудно придумать для Look, но она регулярно становится нужна то тут, то там.)
Для работы с несколькими сессиями – либо Dump/Load (к сожалению, иногда не осиливает Zeroxed окна), либо второй инстанс Acme. Как запустить два инстанса написано в man 4 intro |grep NAMESPACE.
acme-lsp не тестил. Я юзаю gopls, который не требует ручного запуска сервера и имеет дружелюбный командный интерфейс. Но я всё-таки написал парочку обёрток, которые делают переход к символу/список упоминаний/проч более удобным и в духе Acme.
Для подсвечивания ошибок в коде в реальном времени использую go vet в связке с Watch.
Структурные регулярные выражения рулят. К сожалению, многие возможности скрываются за идиомами, которые не всегда видно сразу. Использование адресов открывает многие возможности.
Часто пользуюсь окнами, которые не являются файлом, но благодаря названию /Users/kaldeon/project/-slowquery указывают директорию и организовывают работу.
Sam мне тоже нравится, но он как будто не такой динамичный.
С паролями/секретами также работаю через Acme. Просто шифрую файл через gnupg. Если требуется ввести пароль, то win gnupg --decrypt file, иначе достаточно пайпов.
Когда сидел на линуксе, то ещё больше делал через команды, включая работу с systemd, подключение к wifi, смену раскладки, регулировку яркости экрана, создание скриншотов, просмотр времени и даты — всё перечисленное без шорткатов, только обычные команды в файлах — но в связи с переходом на макось уже так не делаю.
Странно, но сам отказался от vscode и перешел на emacs-nox.
Настроил tree-sitter для покрытия тех ЯП, с которыми кручусь (да, много) и пользуюсь с grep на пару. Удобно, мгновенно, убрал все эти modes, так как самая большая необходимость - отступы и выравнивание.
Код практически без подсветки (только строки и комментарии отличаются по цвету). Это позволяет читать что угодно и где угодно.
Дядь. Да сиди ты на JB. Этот подход тоже имеет место быть. Да, он от Windows. Ну будь на Linux как пользователь Windows, чё нет-то?
Тот же Rob Pike или атэц Си - они пользуют набор инструментов, которые в корне отличаются от IDE. Что могу написать - Этот подход начинаешь понимать после плотного программирования на Bash и иже с ними. Так как хочешь хорошо писать, а для этого надо учить этот набор инструментов.
JB/VS проигрывают в мире мультипрограммирования. У меня только сейчас стек из +-10 ЯП. Понял, что главное - минимум цвета (или отсутствие), понимание отступов под многие ЯП и «не мешать».
Здесь конкретно выходят на топчик Emacs/Vim. Вим - так как везде и имеет один файл на конфиг (Puppet или альтернативы спасают пацанов). Emacs - так как можно сделать при должном умении всё. С инструментарием и командной строкой можно быстро вникнуть и разобраться (Tmux/Screen и утилиты (sed, awk, grep etc) или Tiled WM). А JB будет только индексировать монорепу, покрикивая, что на этой машине память тю-тю.
они пользуют набор инструментов, которые в корне отличаются от IDE. Что могу написать - Этот подход начинаешь понимать после плотного программирования на Bash и иже с ними.
В каком-то смысле это IDE, только под E — Envinronment тут подразумевается весь линукс целиком. Я пробовал тыркнуться в этом направлении, но без emacs’овых клавиатурных аккордов тяжко. Привык к этому делу.
Мальчик, я на «этих ваших линуксах» работаю с 2001 года, на emacs просидел 20 лет, поэтому не надо про опыт. То что от emacs можно получить только после длительной и мучительной настройки в продуктах jb просто работает.
Что у тебя за стек из 10 языков? Огласи, пожалуйста, весь список.
Мальчик, я на «этих ваших линуксах» работаю с 2001 года
Крут, я с 95. По писькомеру - ты дно. Это раз. Второе - я же не говорил, что не-не! Только не jb. Я писал, что надо понимать, а это не возраст, это конкретно знание.
Пересобираешь слакварь и настраиваешь имакс с 95 года?) Я тебе пытаюсь сказать, что знание emacs не делает тебя эффективнее тех, кто пользуется другими средствами. Если ты этого не понимаешь, то я не верю, что ты в 95-ом хотя бы родился.
И всё-таки какой у тебя стек из 10 языков? Или к слову ляпнул?
python, bash, c, cpp, go, csharp (иногда F#), sql, java, js/ts, html/css, xml/yaml/toml/json, cl/elisp и немного haskell. Приходится читать и править php код и иногда perl. Но это не основа. Это необходимость. И сейчас отходим от cpp и java (переводим на csharp). Больше на поддержку, чем написание нового.
Пересобираешь слакварь и настраиваешь имакс с 95 года?
В 98 уже на шапке крутился первый сервер (хотя те времена увожали BSD). Про Emacs и слыхом не слыхивал до 2005, со Слакой не сложилось, работал(ю) или с бинарными или с Gentoo/Crux.
Дополню:
Я тебе пытаюсь сказать, что знание emacs не делает тебя эффективнее тех, кто пользуется другими средствами.
Тут мне нечего сказать. Я принципиально не могу с тобой поделиться сравнением, если не с чем сравнивать. В защиту могу сказать, что после длительного «сидения» на, допустим, Vim, тебя уговорили пересесть на VSCode с его клавишами по умолчанию. Такое ощущение после Emacs в другой среде - то это не настроить (намертво прибито или отсутствует), то это поведение. Вроде и не главное, а страшно бесит и пропадает комфорт от использования.
Это как с едой. Пока не узнал, что есть другие блюда и кухни, которые ближе к тебе по составу/вкусу, то так и ешь, что готовят тебе. Но есть и обратная сторона - надо интересоваться готовкой (а лучше стать поваром) или платить за настроенное другими (и это не webstorm/datagrip/rider/golang/clion), там товар и ценник другой.
Внушает, только зачем так расточать свои силы?) У меня сейчас актуальный стек: шарп, sql и немного typescript с react, xml и json можно даже не упонинать. Со всем этим можно работать не выходя из Райдера, вплоть до выполнения sql в строковых литералах и бесшовного дебага бэка и фронта в одной сессии.