Emacs в 2025 році? Так. І ось чому

Я священник Православної Церкви України, отець Михайло. А ще більше 30 років пишу код. Буває й таке😀. За цей час я працював з купою IDE, редакторів текстів і середовищ розробки, але Emacs залишається незмінним інструментом вже більше 20 років і планую використовувати його і надалі. Якщо це не підігріло ваш апетит, то листайте далі 😀

Колись давно точилися баталії йшло змагання між мовами C та Pascal. В процесі розвитку Pascal роздвоївся на дві основні гілки: Delphi та FreePascal. Це не допомогло йому втримати аудиторію, але мені довелося працювати з ними обома. Дещо краще було з Delphi, де був такий-сякий текстовий редактор, багато бібліотек, які там називались компонентами. Але було сумно з інтеграцією зовнішніх засобів, наприклад, систем контролю версій, кодуваннями чи вкрай невдала компонентна модель. FreePascal мав гарний кросплатформений компілятор, який можна було прив’язати до make — системи компіляції та управління задачами. Але не було сторонніх бібліотек та текстового редактора.

Спробувавши доступні редактори і не задовольнившись жодним я, нарешті, спробував Emacs. Попри високий поріг входу, він чудово працював з купою кодувань та мов та мав інтегровану роботу з make. Мої перші конфіги були жахливою копіпастою, але вони закрили мої потреби, а я закохався у такий спосіб налаштування програм. В результаті розробка на FreePascal значно спростилася.

Зрештою, я відмовився від Delphi/Pascal на користь Python та Emacs. Хоча там і не було пристойного автодоповнення, як у Delphi, та й, по-хорошому, не може бути дотепер, мова дозволяла зробити складні речі дуже швидко, тому десь за 3 місяці написав ядро CRUD з декларативним визначенням звітів та GUI, яке генерувалось на основі SQL-запитів. На Delphi мені знадобився б десь рік. Писав я під Windows, але через її незручність почав працювати на Linux.

Пройшли роки і Linux ставав тільки кращим, особливо у плані програмування. Python як не викликав у мене захвату тоді, так не викликає і досі, а Java виявилась чудовою. Ці два інструменти стали основними засобами розробки на роки. За цей час з’являлись, сяяли і зникали редактори коду та IDE, я експериментував з купою мов та різними напрямками в розробці, але Emacs завжди був поруч, як той швейцарський ніж:

• потрібно зайти на віддалену машину та щось написати — а що краще за emacs це вміє?
• хайп навколо нової мови чи поправити якийсь конфігураційний файл — в Emacs вже є мінімальний робочий режим.
• потрібно написати статтю, документацію чи спланувати роботу — org-mode чудовий. Власне, в ньому і пишеться ця стаття.
• працюєш з різним освітленням на різних моніторах — emacs просто підлаштується і під це.

У 2021-му році моя робота змістилась в сторону Internet Of Things (IoT) і моїм основним, бо є GPIO[^1], та улюбленим, бо можна покласти в кишеню, інструментом, став Raspberry Pi. А у 2022 році росія розпочала широкомасштабне вторгнення і я поїхав у інше місце, подалі від стрілянини. Інтернет там був поганий, не найкращі умови для віддаленої роботи. І тут Emacs розкрив свій потенціал: він досить швидко працює як на слабенькому Raspberry Pi так і віддалено по ssh, отже можна мати засіб розробки прямо на пристрої, який ти розробляєш!

Це модуль розумного будинку. Emacs крутиться і тут.

Досить скоро росіяни почали виносити енергетичну інфраструктуру і тут проявилися переваги Raspberry: він не тільки маленький, його, через перехідник, можна заживити і від автомобільного акумулятора. Ці нетипові, для сучасного програміста, умови прояснили для мене багато речей, про які я знав, використовував, але які були, все-таки філософією, а не практичним керівництвом[^2].

Але досить лірики, не за тим ви відкривали статтю. Поговорімо, краще про ⬇️

Текстові редактори vs IDE

Колись давно, коли здавалось, що життя таке ж нескінченне, як Чумацький шлях, я приймав участь у навколокомп’ютерних срачах, холіварах. Срались про те, яке пиво смачніше що краще: вінда, лінукс, чи фрібсд; яка мова крутіша і, обов’язково, яка IDE краща і чи, взагалі, потрібен в наш час текстовий редактор[^3]. В багатьох типових випадках IDE буде кращою за просто текстовий редактор, і я вписав Ідею в свій робочий процес та й в Emacs я намагаюся прикрутити функції IDE, якщо вони просто прикручуються або не тормозять. Але, на мою думку, прорив у функціональності досягається вдалою комбінацією невеликої кількості простих рішень, а не одним комбайном. І саме в цьому контексті текстовий редактор стає корисним, якщо ви слідуєте концепції ⬇️

Unix Way

Напевне, всі програмісти чули про це. Це принцип організації роботи складних систем, побудований на комбінації простих рішень. Ці принципи були сформовані в часи, коли комп’ютери були ще великими, дорогими, повільними, а заводити інформацію в них було значно складніше, ніж зараз. Але тоді писався чудовий софт, який робив складні речі і який зараз би вимагав на порядки потужнішого обладнання та засобів розробки. Тоді це були саме принципи розробки, методичка, а не шанована, але безплідна філософія! IoT-ня та війна помістили мене в такі умови, коли я теж працював в умовах, наближених до тих, де було сформульовано Unix Way.

З однієї сторони, це фізична організація робочого процесу: у тебе може не бути зручної клавіатури, великого монітора чи швидкої мережі. Зрештою, я старий став, лінивий і на додачу до інструментів перти на об’єкт ще й ноутбук мені ліньки та й жалко, як десь гепнеш. От я і працюю з мобільника.

Коли тобі повільно і незручно, то ти дуже добре розумієш, що система повинна бути осяжною. Навіть в комфортному офісі, чим менше коду, тим краще. Тому думай, не про те, щоб додати фічі, а щоб побудувати мінімалістичне ядро, до якого, за потреби підключити потрібну функціональність. Якщо програма на C, то потрібно бути уважнішим, бо легко додати багів. Якщо функція більше 15 рядків, думай над дизайном. Тому і сказано: Do One Thing And Do It Well. Саме з цього принципа виходить текстовий вихлоп, який легко завернути в логи, просто перевірити та, базуючись на ньому, поєднати програми, які легко замінити, якщо що. Та і в контролер ти багато коду не запхнеш[^4]. І важливою частиною роботи стає ⬇️

Текстовий редактор

Найбільшою відміною текстового редактора від IDE є його простота. Найперше, що він має вміти — це швидко запуститись, підсвітити код, зробити швидкий пошук-заміну тексту, з мінімумом рухів запустити програму, побачити результат і повернутись до коду. На невеликій програмі чи конфігові не потрібно складного автодоповнення, дебагера або рефакторига — лог прекрасен, а весь Unix Way будується навколо простоти і мінімалізму. Такі редактори, як nano, mcedit чи vi добре вписуються в цю концепцію. Через реактивність та простоту їх зручно зробити типовим редактором в системі. Але один редактор, здається, не відповідає вимогам і це ⬇️

Emacs

Якщо бути чесним, в Emacs із коробки немає хорошого текстового редактора, навіть прийнятних налаштувань теж немає. Він поставляється з комбінаціями клавіш, які неактуальні ще з початку 80-х, бо тих клавіатур вже немає, але сам Emacs залишається корисним та актуальним.

Ті самі клавіатури, під які заточувалися сполучення клавіш. Тоді все було логічно та зручно, та й взагалі порядок був, а не те шо січас.

Бо Emacs — це не редактор, це система. Він був створений під сильним впливом Lisp-машин і є Lisp-середовищем з усіма плюшками і недоліками цього підходу: власне, мовою, що схожа на Common Lisp, інтерактивною розробкою, конфігурацією системи на цій мові, текстовим та графічним інтерфейсом на вибір, швидким стартом і щільною взаємодією із системою на якій він крутиться. Все це породило купу розширень, які дозволяють виконувати широкий спектр задач. Звісно, купа редакторів та всі IDE вміють взаємодіяти з операційною системою, але GUI не дає добратись до них по ssh.

Складні речі краще налаштовувати в текстовому файлі, а конфігурація IDE здійснюється через вікно налаштувань, де легко щось запороти. Мені стає погано коли потрібно лізти в налаштування Ідеї [^5]. Такі конфіги важко розповсюдити деінде, доводиться витягати його з архіва, заливати а github, на іншій машині його підкидати. Не факт, що пройде гладно через сумісність версій IDE і формату запису. API IDE, як правило, складніше, і застосувати розширення поза межами комп’ютера, де вони розроблялися довше. Тож мати однакові налаштування IDE скрізь, де ти працюєш значно складніше. Перевага Emacs — це текстовий конфіг, зроби git pull на новій машині — і отримаєш актуальний стан свого Emacs скрізь!

І є те, чого я не спостерігав ніде більше: це середовище, яким надихалися тайлові оболонки. Можна розділити вікно на кілька частин, буферів в термінології emacs, і бачити кілька файлів або різні частини одного файлу одночасно! Саме поєднання цих принципів робить Emacs актуальним сьогодні.

Робочий процес

Щоб почати я зазвичай розпаковую архів з налаштуваннями Emacs. Там вже всі потрібні розширення, і основа у вигляді історії git. Далі git pull і все працює. Далі вступає в гру система зборки — make. За допомогою цієї утиліти дуже просто автоматизувати весь процес розробки більшості проектів починаючи від ініціалізації, продовжуючи керуванням залежностями, зборкою, тестуванням і деплоєм проекта. І по ходу діла описувати та відслідковувати роботу в Readme.org. Навіть для Java, хоча я і розробляю все в IDE, є корисним завернути maven в make, щоб щось віддалено швиденько поправити та зробити make deploy. Єдине, де такий підхід не спрацював, це розробка під Android.

Коли працюєш з телефону, прийоми роботи відмінні від роботи за комп’ютером відчуваєш дискомфорт: за комп’ютером у мене відкрито кілька терміналів між якими легко перемикатись. Там зручно лазити по каталогам та переглядати файли. На телефоні незручне перемикання між вікнами. На щастя, в Emacs є свій файловий менеджер — dired. Але з коробки все незручно відсортовано та перемішано, то я написав розширення для сортування та попереднього перегляду. Тепер не потрібно тримати окремі консолі для перегляду та редагування файлів.

Варто сказати, що потреби допилювати dired дуже довго не було, тому, що в Emacs дуже зручно відкривати файли, особливо якщо налаштовано ⬇️

Completion

В Emacs може не бути просунутого доповнення для певної мови, але є два режими, які часто використовуються: company-mode провадить стандартне віконечко з варіантами та документацією. Але є і більш вдале рішення на базі окремого буферу — completion. Ось як у мене працюють обидва варіанти:

(setq completions-format ’one-column)
(setq completions-header-format nil)
(setq completions-max-height 20)
(setq completion-auto-select nil)
(define-key minibuffer-mode-map (kbd «C-n») ’minibuffer-next-completion)
(define-key minibuffer-mode-map (kbd «C-p») ’minibuffer-previous-completion)
(define-key completion-in-region-mode-map (kbd «C-n») ’minibuffer-next-completion)
(define-key completion-in-region-mode-map (kbd «C-p») ’minibuffer-previous-completion)
(defun my/minibuffer-choose-completion (&optional no-exit no-quit)
(interactive «P»)
(with-minibuffer-completions-window
(let ((completion-use-base-affixes nil))
(choose-completion nil no-exit no-quit))))
(define-key completion-in-region-mode-map (kbd «M-RET») ’my/minibuffer-choose-completion)
;; marginalia-mode
(marginalia-mode t)
(setq marginalia-field-width 50)
;; company-mode
(add-hook ’after-init-hook ’global-company-mode)
(global-set-key (kbd «\e\em») ’company-complete)
(company-quickhelp-mode)
(setq company-quickhelp-delay 3)
(setq company-idle-delay nil)

Compilation

Буфер компіляції. Можна запустити компіляцію використовуючи make compile і, якщо є помилки, цей буфер перенаправить вас в потрібне місце в коді. А можна перетворити його в монітор роботи програми, виконавши make run чи python mycode.py. Одним з налаштувань цього режиму є розумне розширення під вміст буфера. В звичайному стані цей буфер знаходиться ніби у звернутому стані, займаючи мінімум місця (але достатньо для спостереження боковим зором), а при перемиканні в нього адаптується під розмір тексту. такої поведінки я ще не бачив в IDE. Для мене це важливо, бо розумно розподіляє увагу між кодом і вихлопом, який мене цікавить і мінімізує кількість моїх рухів. Ось мій хак, щоб це запрацювало:

(require 'popwin)
(popwin-mode 1)

(setq popwin:special-display-config
      '(("*Help*" :position right :width 40 :stick t)
        ("*Messages*" :position bottom :height 10 :stick t)
        ("*compilation*" :position bottom :height 15 :stick t :regexp t)
        ("*eshell*" :position bottom :height 15 :stick t)
        ("^\\*helpful.*" :position right :width 0.4 :stick t :regexp t)
        ))

(defvar my-window-max-height 25
  "Height of the window when it is active.")

(defvar my-window-min-height 10
  "Minimum height of the window when it is not active.")

(defun my-adjust-popwin-windows ()
  "Minimum height of the window when it is not active."
  (dolist (win (window-list))
    (let ((buf (window-buffer win)))
      (when (and buf
                 (assoc (buffer-name buf) popwin:special-display-config))
        (let ((config (cdr (assoc (buffer-name buf) popwin:special-display-config))))
          (when (eq (plist-get config :position) 'bottom)
            (if (eq (selected-window) win)
                (with-selected-window win
                  (enlarge-window (- my-window-max-height (window-height))))
              (with-selected-window win
                (shrink-window (- (window-height) my-window-min-height))))))))))

(add-hook 'window-selection-change-functions
          (lambda (_) (my-adjust-popwin-windows)))

А як же без...

• дебагера? Режим compilation + системи логування чудові. Єдине, де я користуюсь дебагером, це Android. І то, тільки тому, що logcat став незручним.
• автодоповнення та навігації по коду? По-перше, таке-сяке автодоповнення для більшості мов є. Для Java все сумно, є тільки базове автодоповнення, але і з цим можна жити. Як не дивно, але без автодоповнення можна працювати, а от швидкість відгуку системи для мене важливіше. Навігація по коду теж багато для чого є, хоч на рівні language-mode, хоч на рівні тегів (у мене налаштовано автоматичне оновлення тегів при зберіганні).
• рефакторинга? Це той момент, коли потрібна IDE :)
• управління проектом? Emacs має кілька систем управління проектом, наприклад, projectile. Я не люблю ставити лишні розширення, тому використовую базовий .dir-locals.el
• системи контролю версій? Рідний vsc непоганий, а magit чудовий.
• без зручної клавіатури, наприклад на телефоні? По-перше є безпроводна міні-клавіатура, жити можна. По-друге, стандартні сполучення клавіш типу Ctrl-F/B/P/N з стають у нагоді, особливо, якщо погано попадаєш по стрілкам.

Що ще?

Потенціал Emacs Lisp, мови розширень Emacs, недооцінений. Це потужна та зріла мова, а Emacs надає купу зручностей для неї: REPL, автодоповнення, гарну документацію, можливість взаємодії з системою. І купу бібліотек, які доступні у вигляді готових пакетів. Ви можете використовувати її не тільки для розширень, а і для купи разових задач, не вартих навіть окремого файла для зберігання, як то скачати дані, розпарсити їх і т.і. В принципі там є все, щоб крутити якісь сервіси з можливістю оновлення коду без перезапуска.

Приклад разової задачі

Стандартна задача аналізу лога. У мене є регулятор, який читає значення температури та вологості. В процесі розробки я пишу лог який я і хочу проаналізувати. Я запускаю make run і в буфері Compilation виводиться щось на кшталт:

t 10
t 12
t 18
h 80
t 25
t 30
t 33
h 77
t 31
t 28

Тепер потрібно відфільтрувати значення >= 30, щоб подивитись, як відпрацьовує регулятор. Є кілька способів це зробити. Самий простий, віділити потрібні рядки, викликати shell-command-on-region та передати його в Unix-way спосіб:

awk '$1 == "t" && $2 >= 30'
t 30
t 33
t 31

Але лог, як правило, великий, незручно виділяти, викликати і т.і. Можна просто скормити вміст буфера *compilation* lisp-кодові. І навіть більше, можна організувати роботу з ним в стилі Unix-way.

В Emacs є буфер*scratch* для виконання lisp-кода. От його я і використовую для разових задач. Тут функція my/with-compilation-buffer передає вміст буфера *compilation* в my/filter-compilation-temp.

(defun my/filter-compilation-lines (lines)
  "Filter LINES starting with 't' where value >= 30."
  (let ((results nil))
    (dolist (line lines results)
      (when (and (stringp line)
                 (string-match "^t \\([0-9]+\\)$" line)
                 (>= (string-to-number (match-string 1 line)) 30))
        (push line results)))))

(defun my/with-compilation-buffer (handler)
  "Call HANDLER with the lines of the *compilation* buffer as a list."
  (with-current-buffer "*compilation*"
    (funcall handler (split-string (buffer-string) "\n"))))

(defun my/filter-compilation-temp (lines)
  "Filter LINES starting with 't' where value >= 30 and print to stdout."
  (interactive)
  (let ((results (my/filter-compilation-lines lines)))
    (if results
        (with-temp-buffer
          (dolist (result results)
            (insert (format "%s\n" result)))
          (princ (buffer-string) t)))))

Залишилось лише викликати (my/with-compilation-buffer 'my/filter-compilation-temp). Це можна зробити в чомусь, що підтримує виклик функції: консолі ielm, прямо тут, в *scratch* або в інтерактивному виклику натиснувши M-:

Але саме цікавіше, що в Emacs вбудовано команну оболонку, eshell. Вона дозволяє вивести результат у змінну чи передати конвеєром

eshell> (my/with-compilation-buffer 'my/filter-compilation-temp)
t 30
t 33
t 31
eshell> (my/with-compilation-buffer 'my/filter-compilation-temp) | wc -l
3

Нажаль, eshell ще не навчився приймати вхідний текст через пайп, але можна вивести у змінну echo "Hello eshell" | wc -c > #'myvar. Якшо не потрібно використовувати результат в стилі Unix-way, то код буде ще коротшим.

Більше про eshell можна дізнатись з цієї статті.

Закінчення

Коли ти слідкуєш за простотою системи, складні інструменти і великі ресурси вже не критичні[^6]. Звісно, в мене є значно потужніше залізо, ніж телефон чи Raspberry Pi, але саме поєднання Linux, make та Emacs дозволяє ефективно писати код та організовувати процеси навколо нього. Звісно, є те, що не буває простим, в моєму випадку це були розробка під mobile або бухгалтерія, тут Unix Way не буде працювати.

Хоча я находжу Emacs оптимальним, але є ще два популярні інструменти, які роблять приблизто теж саме. Це Vim та VSCode. Обидва мають приблизно ті ж можливості: складніші за тупий редактор, але недотягують до IDE, всі троє налаштовуються, мають мову розширень. Головним недоліком Vim є те, що він псує текст 😉, а мова конфігурації гірша за Lisp. До VSCode не доберешся по ssh і він все-таки повільніший, а швидкість відгуку редактора для мене залишається вагомим аргументом. Заради цього я готовий пожертвувати просунутим автокомплітом.

Всі три редактори підтримують сучасні мови через lsp-mode, що забезпечує автодоповнення та навігацію по коду для Python, JavaScript та купи інших мов, наближаючи його до можливостей IDE, але втрачається простота і швидкість, які я так ціню.

З написаного видно протиріччя: як Emacs суміщаться з Unix Way, з його простотою та мінімалістичністю? Emacs достатньо швидкий, щоб залишатись текстовим редактором, звісно, якщо з нього не ліпити IDE. Я надаю перевагу простим та швидким режимам з базовим функціоналом, як то підсвітка синтаксису, робота з VCS, інтеграція з системою та універсальним автокомплітом. В моєму випадкові це чудово працює як само-по-собі на легких проектах, так і в парі з IDE.

Тут я згадав лише основні моменти, чому Emacs актуальний для мене, а по багатьом з них можна було б написати по статті. Для когось цей підхід не відкриє нічого нового, а хтось, можливо, відкриє для себе чудові пласти програмістської культури. Зрештою, вагомою частиною програмування є фан. UNIX, Lisp, Emacs і все довколо них розробляли дуже талановиті і, напевно, геніальні люди. Атмосфера вільних, творчих, сміливих та рок-н-рольних 70-х досі присутня в цих інструментах, а винаходи того часу досі не втрачають актуальності. Якщо ви ще не торкнулись цього, то все просто виправити:

sudo apt install emacs

Footnotes

[^1]: GPIO — інтерфейс для підключення датчиків

[^2]: Як же це схоже на ситуацію в християнстві!

[^3]: Звісно, дати відповідь чи варто вкладатись в ту чи іншу технологію такі срачі не можуть, дешевше і швидше попробувати зробити щось на кожній з них і вирішити для себе що, де і за яких умов краще.

[^4]: Знаю, тепер це вже неактуально, python туди запхали 😀

[^5]: Якщо налаштовувати Emacs через вікно налаштувань, стає ще гірше

[^6]: Це перегукується з практикою християнства, де одним з побічних ефектів є перемикання з володіння на буття. В цей час якби самі-по-собі відпадають купа речей, звичок, намірів і людей. І от таке простіше життя приносить радість. Але це вже інша історія.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті