Emacs і Vim у добу штучного інтелекту | (think)
https://ift.tt/WOQCPBa
«Не легко робити прогнози, особливо щодо майбутнього.»
– Йогі Берра
Я вже понад 20 років фанат Emacs. Я створював і підтримував деякі з найпопулярніших пакетів для Emacs, вносив внесок у сам Emacs і провів безліч годин, налаштовуючи свою конфігурацію. Emacs — це не лише мій редактор — це моя пристрасть, моє щасливе місце.
За останній рік я також багато часу присвячував Vim та Neovim, вивчаючи їх заново з нуля і радіючи порівнянню того, як обидві спільноти підходять до подібних проблем. Це був веселий і освіжаючий досвід.
І останнім часом, як і всі в нашій галузі, я експериментую з інструментами штучного інтелекту — зокрема Claude Code — спостерігаю вплив AI на ширший ландшафт програмування і думаю, що все це означає для майбутнього програмування. Природно, я знову повертаюся до одного й того самого питання: що станеться з моїм улюбленим Emacs та його “arch nemesis” Vim у цьому сміливому новому світі?
Я думаю, відповідь більш нюансована, ніж просто “вони приречені” або “зміни відсутні взагалі”. Прогнозування майбутнього тяжке, але спекуляція невідступна.
Ризики
Єдине, що стабільне — це зміна.
– Геракліт
Кожна велика технологічна революція приносить як виклики, так і можливості. Річ не про чорно-біло: все має відтінок сірого. Революція штучного інтелекту не є винятком, і варто чесно розглянути обидві сторони перед висновками.
Почнемо з викликів.
Гравітаційна well IDE
VS Code вже домінує як редактор з великим відривом, і він отримає інтеграції в усі основні інструменти AI — Copilot (очевидно), Codex, Claude, Gemini, усе інше. Microsoft має всі стимули зробити VS Code найкращим можливим хостом для розробки з підтримкою AI та ресурси для цього.
До того ж, спеціалізовані AI-редактори, такі як Cursor, Windsurf та інші, привертають значні інвестиції та таланти. Вони не додають AI до існуючного редактора як після думки — вони будують увесь досвід навколо AI-робочих процесів. Вони пропонують інтегроване управління контекстом, вбудовані дифи, багатофайлове редагування та агентські петлі, що здаються рідними, а не прикріпленими зверху.
Кожен розробник, який переходить на ці інструменти, це розробник, який не вчиться Emacs або Vim-कлавіатур, не пише Elisp і не вносить свій внесок у наші екосистеми. Гравітаційна здатність реальна.
Крім того, спеціально розроблені AI-редактори на кшталт Cursor, Windsurf та інші залучають серйозні інвестиції та таланти. Вони не додають AI до існуючого редактора як післядумку — вони будують увесь досвід навколо AI-робочих процесів. Вони пропонують інтегроване управління контекстом, вбудовані різниці, багатофайлове редагування та петлі агентів, що виглядають нативно, а не болтно.
Кожен розробник, який переходить на один із цих інструментів, — це розробник, який не вчиться Emacs або Vim, не пише Elisp і не долучається до наших екосистем. Гравітаційна яма реальна.
«Я ніколи не пробував Cursor і Windsurf просто тому, що вони фактично є форками VS Code, і я не терплю VS Code. Я пробував його кілька разів за роки і ніколи не відчував себе продуктивним з різних причин.»
Частина кейсу за Emacs та Vim завжди була в тому, що вони роблять вас швидшими у написанні та редагуванні коду. Комбінації клавіш, макроси, розширюваність — усе це на службі підвищення ефективності людини в механічному акті кодування.
Але якщо AI пише більшість вашого коду, наскільки швидко механічне редагування має значення? Коли ви переглядаєте та коригуєте згенеровані AI-дифи замість того, щоб друкувати код символ за символом, вузьке місце переходить від “наскільки швидко можу редагувати” до “наскільки добре можу вказати намір та оцінити вивід.” Це принципово інша навичка, і не зрозуміло, що Emacs чи Vim мають в цьому природну перевагу.
Аргумент про навчальну криву стає також важчим для виправдання. “Проведи шість місяців, вивчаючи Emacs, і ти станеш у 10 разів швидшим” — це важкий продаж, коли молодший розробник з Cursor може швидко зібрати цілий застосунок за одну пополудні. Проте питання про те, що саме ви редагуєте, може мати більш цікаву відповідь, ніж здається на перший погляд.
Корпоративна асиметрія підтримки
VS Code має Microsoft. Cursor має венчурний капітал. Emacs має… невелику групу волонтерів та FSF. Vim мав Bram (Брам), а зараз має спільноту підтримуючих. Neovim має невелику, але віддану ядро-команду.
Це завжди було так, звісно, але AI збільшує розрив. Побудова глибоких інтеграцій з AI потребує тримати крок із швидко мінливими API, моделями та парадигмами. Добре фінансовані команди можуть присвячувати інженерів цієї справі повний робочий день. Добровільно керовані проєкти розвиваються у темпі вільного часу та ентузіазму людей.
Сценарій кінець світу
Пійдемо на повну: що якби програмування, як ми його знаємо, повністю було б автоматизовано протягом наступного десятиліття? Якщо AI-агенти можуть взяти специфікацію та створити робоче, протестоване, розгорнуте програмне забезпечення без участі людини, нам більше не знадобляться кодувальні редактори взагалі. Ні Emacs, ні Vim, ні VS Code, ні Cursor. Уся категорія стає неактуальною.
Я не думаю, що це ймовірно найближчим часом, але варто визнати як потенціал. Траєкторія можливостей AI здивувала навіть оптимістів (я сам спочатку був скептиком щодо AI, але швидкі здобутки минулого року зламали мою думку).
Можливості
Той малюнок видає жорстокий прогноз, але ось справа — Emacs і Vim багато разів відкидали. Eclipse мав їх знищити. IntelliJ мав їх знищити. VS Code мав їх знищити. Sublime Text, Atom, TextMate — все нібито мали стати останнім цвяхом у домовині. Більшість з цих “вбивць” самі померли або зменшилися, тоді як Emacs та Vim продовжують існувати. В них є стійкість, яку легко недооцінювати.
Тож розглянемо інший бік монети.
AI допомагає вам допомогти собі
Одна з найменш оцінених переваг AI для користувачів Emacs та Vim — це банальне: усунення проблем. Обидва редактори відомі великими кривими навчання та непрозорими повідомленнями про помилки. “Неправильний тип аргументу: stringp, nil” відштовхував більше людей від Emacs, ніж будь-який конкурент колись зробив.
AI-інструменти надзвичайно добре пояснюють заплутані повідомлення про помилки, діагностують конфігураційні проблеми та пропонують виправлення. Вони можуть прочитати ваш іни-файл і виявити проблему. Вони можуть пояснити, що робить шматок Elisp. Вони можуть допомогти зрозуміти, чому ваш клавіатурний зв’язок не працює. Це значно знижує поріг входу — не тим, щоб зробити редактор простішим, а щоб кожному користувачеві дати доступ до терплячого, обізнаного гіда.
Я особисто не потребую AI-підтримки для відлагодження чого-небудь в моїй конфігурації Emacs, але це іноді було корисно в Neovim-землі, де мої знання порівняно скромні.
«Існує щонайменше один задокументований випадок, коли хтось повернувся до Emacs після багатьох років відмови, саме тому що Claude Code зробив безболісним виправлення конфігураційних проблем. Вони пішли до IntelliJ через те, що конфігураційне навантаження стало дратуючим — і повернулися, як тільки AI зняло цей бар’єр. “Щасливі, чоканите дні, я вдома знову,” як вони це висловили. Якщо AI може повернути до Emacs користувачів, які давно не використовували його, це добре в моїх очах.»
AI робить конфігурацію та розширення тривіальними
Ось що майже ніхто не обговорює: Emacs і Vim завжди страждали від непрозорості своїх мов розширення. Emacs Lisp — діалект Lisp 1980-х років, який більшість програмістів ніколи не бачили раніше. VimScript — це… VimScript. Навіть Lua, який Neovim прийняв саме тому, що він більш доступний, настільки нишевий, що більшість розробників ніколи не написали його рядка.
Це було найбільшим вузьким місцем для обох екосистем. Не самі редактори — вони надзвичайно потужні — але факт, що їхнє налаштування вимагає вивчення незнайомої мови, і більшість людей ніколи не доходила до копіювання фрагментів з блогів та READMEs.
Я відчував неймовірний тиск Elisp та VimScript, коли вперше вчив Emacs і Vim, і уявляю, що не був єдиним. Я почав відчувати себе дуже продуктивним в Emacs лише після того, як витратив чимало часу на те, щоб справді вивчити Elisp. (Ніколи не збирався робити те саме з VimScript, і не дуже хочу освоювати Lua.)
AI змінює це за одну ніч. Тепер ви можете описати те, що хочете, просто англійською, і отримати працюючий Elisp, VimScript або Lua. “Напиши мені функцію Emacs, що переформатує поточний абзац на 72 колонки і додасть префікс” — зроблено. “Налаштуй lazy.nvim, щоб встановити LSP з цими клавіатурними зв’язками” — зроблено. Бар’єр мови розширень, який був найбільшою перешкодою для впровадження протягом десятиліть, раптом знижено значно.
Також те саме стосується розвитку плагінів
Після понад 20 років у спільноті Emacs у мене часто є відчуття, що відносно невелика група — можливо 50–100 людей — рухає більшість значущого прогресу. Одні й ті самі імена з’являються в MELPA, на розсилках та в звітах про помилки. Це не критика цих людей (я пишаюся тим, що маю серед них місце), але це структурна слабкість. Спільнота, яка залежить від такої малої кількості учасників, крихка.
І це не лише Elisp і VimScript. C-ядро обох Emacs і Vim (і C-ядро Neovim) підтримується ще меншою групою. Знайти людей, які готові та здатні хитро маніпулювати десятиліттями старими кодовими базами на C, дійсно важко, і з кожним роком стає важче, оскільки все менше розробників вивчає C взагалі.
AI-інструменти можуть допомогти тут у два способи. По-перше, вони знижують бар’єр для нових учасників — хтось, хто розуміє концепцію того, що хоче побудувати, тепер може отримати AI-підтримку з реалізацією на незнайомій мові. По-друге, вони допомагають існуючим підтримувачам рухатися швидше. Я особисто помітив, що AI відмінно генерує тести-скелети, пише документацію та обробляє нудні частини підтримки пакетів, що уповільнюють усе.
AI-інтеграції вже відбуваються
Спільноти Emacs та Neovim не сидять складно. Уже є вражаючі інтеграції AI:
Emacs:
– gptel — багатофункціональний клієнт LLM, що підтримує кілька бекендiв (Claude, GPT, Gemini, локальні моделі)
– ellama — інтерфейс Emacs для взаємодії з LLM через llama.cpp та Ollama
– aider.el — інтеграція Emacs для Aider, популярного інструменту парного програмування з AI
– copilot.el — інтеграція GitHub Copilot (я випадково нині є основним підтримувачем проєкту)
– elysium — штучно-підтриманий помічник кодування з вбудованим застосуванням дифів
– agent-shell — рідний буфер Emacs для взаємодії з агентами LLM (Claude Code, Gemini CLI тощо) через Agent Client Protocol
– ECA — редактор-незалежний помічник штучного кодування (зроблено на Clojure!), що працює через протокол, подібний до LSP, підтримуючи кілька провайдерів LLM (і Neovim також)
Neovim:
– avante.nvim — Cursor-подібний досвід кодингу з AI всередині Neovim
– codecompanion.nvim — заміна Copilot Chat, що підтримує кілька провайдерів LLM
– copilot.lua — нативна інтеграція Copilot для Neovim
– gp.nvim — сесії на зразок ChatGPT в Neovim із підтримкою кількох постачальників
І це лише зразок. Створення цих інтеграцій не настільки важке, як здається — API прості, а розширюваність обох редакторів означає, що ви можете зв’язати інструменти AI способами, що виглядають природно. З допомогою AI-асистента створення нових інтеграцій стає ще легшим. Я б не здивувався, як швидкість розробки плагінів значно прискориться.
Ось іронія, яка заслуговує більшої уваги: багато з найпотужніших інструментів штучного кодування працюють у терміналі. Claude Code, Aider та різні інструменти Copilot CLI — усе запускаються у терміналі. А у терміналі що живе? Emacs і Vim.
Запуск Claude Code у буфері Emacs vterm або у розділі терміналу Neovim є цілком природним робочим процесом. Ви отримаєте агент AI у одній панелі, а редактор — у іншій, з усіма вашими клавішними прив’язками та інструментами. Немає перемикання між різними додатками — все в одному середовищі.
Це насправді перевага над GUI-орієнтованими AI-редакторами, де інтеграція AI тісно пов’язана з інтерфейсом самого редактора. З термінальними інструментами ви можете вибрати свій власний редактор та своє AI-інструмент, і вони природно поєднуються.
Ще одна перспектива: якщо програмування дедалі більше пов’язане з написанням запитів, а не з кодом, ви все одно користуєтесь відмінним текстовим редактором для цього. Запити — це текст, і добре їх формулювати має значення. Я знаходжу іронією, що Claude Code — інструмент, який я інакше люблю — не використовує readline, тому мої клавіатурні прив’язки Emacs там не працюють правильно, а його емуляція Vim доволі погана. Я вважаю використання React для CLI-додатків помилкою, і підозрюю, що багато людей би віддали перевагу використанню Claude Code всередині Emacs або Vim замість цього. Саме те, що дозволяє ACE (Agent Client Protocol) — він дозволяє таким редакторам, як Emacs (через agent-shell) виступати з вищим рівнем клієнтів для AI-агентів, надаючи вам правильне редагування, прив’язки клавіш і всі потужності вашого редактора під взаємодією з інструментами на кшталт Claude Code. Найкращим редактором запитів може бути той, який ви використовуєте вже десятиліттями.
Emacs як платформа інтеграції з ШІ
Філософія “редактор як операційна система” Emacs унікально добре підходить для інтеграції з AI. Це не просто редактор коду — це клієнт пошти (Gnus, mu4e), система нотаток (Org mode), інтерфейс Git (Magit), емулятор терміналу, файловий менеджер, читач RSS та багато іншого.
AI можна інтегрувати на кожному з цих рівнів. Уявіть собі AI-помічника, який може читати ваш календар в org-mode, складати відповіді на електронні листи в mu4e, допомогти вам написати повідомлення до коміту в Magit і рефакторити код у ваших вихідних буферах — усе в одному середовищі, з спільним контекстом. Жодна інша архітектура редактора не робить таке глибоке, крос-доменне інтегрування таким самим природним чином, як це робить Emacs.
Я перестав користуватися Emacs як своєю ОС дуже давно, зараз я в основному використовую його для програмування та блогінгу. (Я пишу цю статтю в Emacs за допомогою markdown-mode.) Проте, я всього лише один користувач Emacs, і багато хто, мабуть, використовує його більш цілісно.
Навіть у пост-кодинговому апокаліпсисі Emacs та Vim виживають
Повернемося до сценарію кінця світу. Скажімо, програмування повністю автоматизоване, і ніхто більше не пише код. Чи помре Emacs?
Не обов’язково. Emacs уже використовується для куди більшого, ніж програмування. Люди використовують Org mode для управління своїм цілим життям — завдання, нотатки, календарі, щодники, відстеження часу, навіть наукові статті. Emacs є здатним середовищем для письма прози, з відмінною підтримкою LaTeX, Markdown, AsciiDoc і звичайного тексту. Можна читати електронну пошту, переглядати веб-сторінки, керувати файлами і так, грати в Тетріс.
Vim, подібно, є парадигмою редагування тексту так само, як і програмою. Прив’язки клавіш Vim колонізували кожен текстовий ввід у світі обчислень — VS Code, IntelliJ, браузери, оболонки, навіть Emacs (через Evil mode). Навіть якщо сама програма Vim зникне, ідея Vim вічна.
І хто знає — можливо колись з’явиться ринок artisanal, ручної роботи програмного забезпечення, як є ринок для вінілових платівок та механічних годинників. “Органічний, малопартійний код, любовно набраний людиною в Emacs — по одному символу за раз.” Я б придбав таку футболку. І я майже впевнений, що ці ремісники-програмісти не будуть користуватися VS Code.
Тож навіть у найекстримальнішому сценарії обидва редактори мають життя поза кодом. Меншою мірою, можливо, але життя все одно є.
Загальна картина
Я думаю, що відбувається щось цікавіше, ніж “редактори вмирають” або “редактори цілком нормальні”. Роль редактора змінюється.
Протягом десятиліть редактор був тим місцем, де ви писали код. Зараз все більше це місце, де ви переглядаєте, керуєте та вдосконалюєте код, який пише AI. Навички, що мають значення, переходять від швидкості набору та гімнастики редагування до чіткості специфікацій, читання коду та архітектурного судження.
У цьому світі редактор, що виграє, не той, у якого найкраща автодоповідь коду — це той, що дає вам найбільший контроль над вашим робочим процесом. І це завжди була основна цінність Emacs та Vim.
Питання полягає в тому, чи спроможні спільноти швидко адаптуватися. Інструменти є. Архітектура є. Філософія правильна. Потрібні люди — більше розробників, більше авторів плагінів, більше авторів документації, більше голосів у розмові. AI може допомогти зменшити розрив, але не може замінити справжнє залучення спільноти.
Етичний слон у кімнаті
Не кожен у спільнотах Emacs та Vim захоплений AI, і заперечення виходять за рамки чистого технофобії. Є легітимні етичні занепокоєння, які обговорюватимуться тривалий час:
– Енергоспоживання. Навчання та використання великих мовних моделей вимагає величезних обчислювальних потужностей і електроенергії. Для спільнот, які давно цінували ефективність та мінімалізм — користувачів Emacs, які пишаються використанням редактора 40-річної давності, користувачів Vim, які хваляться підс ектовк запуску за мить — екологічна вартість AI важко ігнорується.
– Авторське право та навчальні дані. LLM тренуються на величезних корпусах коду та тексту, і легальність та етика такої підготовки залишаються предметом дискусій. Деякі розробники некомфортно почуваються використовуючи інструменти, які могли навчитися на коді з авторським правом без явної згоди. Ця проблема близька до домашнього поля для спільнот з відкритим кодом, які дуже докладають зусиль до ліцензування.
– Відсування на роботу. Якщо AI зробить розробників значно продуктивнішими, може знадобитися менше людей. Це незручна думка для будь-якої спільноти програмування, і особливо гостро стоїть для редакторів, чия ідентичність побудована на розширенні можливостей людських програмістів.
Ці занепокоєння вже призводять до конкретних дій. Спільнота Vim нещодавно створила EVi, форк Vim, ціллю якого є забезпечення текстового редактора, вільного від AI-доданої (згенерованої?) коду. Чи згодні ви з такою посилкою чи ні, той факт, що люди розгортають форки існуючих редакторів через це, говорить вам, наскільки сильно деякі члени спільноти відчувають це.
Я не думаю, що ці занепокоєння повинні зупинити будь-кого від дослідження інструментів AI, але вони реальні та варто ставитися серйозно. Я очікую побачити багато палких дискусій з цього приводу на emacs-devel та трекерах issues Neovim у наступні роки.
Завершальні думки
“Майбутнє не таке, як раніше.”
– Йогі Берра
Я не збираюся притворятися, що не хвилююся. Хвиля AI рухається швидко, існуючі гравці мають величезні переваги у фінансуванні та увазі аудиторії, а сама природа програмування змінюється під нашими ногами. Цілком можливо, що Emacs та Vim повільно зникнуть у ниші, використовуючись лише кількома відданими ентузіастами, які відмовляються рухатися далі.
Те, що підтримує ці редактори живими, — не впертість, а адаптивність. Спільноти невеликі, але палкі; редактори — більш здатніші, ніж будь-коли; архітектура дійсно добре пристосована до ери AI. Ядро ідеї Vim настільки потужне, що воно продовжує знаходити нове вираження (Neovim — найновіша та найактивніша інкарнація). Emacs продовжує поглинати все, що комп’ютинг-про світ кидає їй, як і завжди.
Редактори, які виживуть, не матимуть найяскравіші AI-фічі. Вони будуть тими, чий користувачі дбають достатньо, щоб продовжувати будувати, адаптувати та ділитися. Це завжди було справжнім двигуном відкритого програмного забезпечення, і жодна кількість AI не змінить цього.
Отже, якщо ви користувач Emacs або Vim: не панікуйте, але й не розслабляйтеся. Вивчайте нові AI-інструменти (якщо ви не принципово проти них). Покращуйте свій налаштування та робіть його чудовим. Пишіть про свої робочі процеси. Допомагайте новачкам. Найкращий спосіб забезпечити виживання вашого редактора в епоху AI — зробити його процвітаючим у цій епосі.
Можливо, майбутнє не таке, як раніше — але це не обов’язково погано.
Цей есейник охопив більше тем, ніж я спочатку планував — багато думок давно вертілися у голові, і я хотів би висловити їх всі. Програмування може бути складним, але написання прозового тексту все ще важке. Проте сподіваюся, що частина цих ідей резонує з вами.
На цьому все на сьогодні. Продовжуйте вдосконалюватися!
P.S. Зацікавлена обговорення Hacker News про цю статтю. Перегляньте, щоб побачити, що думає широка спільнота!
March 15, 2026 at 07:10AM
Залишити відповідь