В названии, конечно, отсылка к фильму Spring, Summer, Fall, Winter… and Spring.
Обещал накатить вброс по Emacs, ибо как писали постом выше, народ заскучал. Речь идет о продолжении топика Жизнь после Emacs.
Вообще, суть моего мессенжа, пожалуй, точнее всего передает это короткое видео :).
Но если все же попытаться раскрыть суть чуть подробнее. Да, лучше Emacs пока никто ничего не придумал, хотя есть интересные попытки. Никакие элементы архаики, сохранившиеся в Emacs не могут преуменьшить те уникальные преимущества, которых больше нигде нет. Тут дело не в том, что в других редакторах/IDE они хуже или, скажем, они пока недоработанные. Их просто нет.
Итак, в продолжении темы предыдущей серии, я перешел на 1,5 года на VS Code.
Плюсы:
- Производительность UI, который рендерится на GPU.
- Производительность JavaScript (спасибо Electron/NodeJS/V8).
- Вменяемый API.
Минусы:
- Не keyboard-centric. Некоторые вещи вообще без мыши не сделать, что раздражает.
- Хотите переименовать текущий файл? Вам нужен плагин для этого! В Emacs это была бы просто небольшая функция - кинул в конфиг и всего делов. Тут же 8 плагинов, половина из них заброшена в 2015-м, другая половина помимо необходимой функции добавляет еще 100500 других. Доков нет, докстрингов нет, что кто-то другой будет открывать код плагина и в мыслях не было. Спасибо, если есть ридми, пусть и не обновляемая много лет, и уже не релевантная коду.
- Культура разработки. Вне официального кода от Microsoft ее нет (см. выше). Писать плагины на ClojureScript возможно, но не вполне натурально (как проба пера, например advanced-navigation-cljs). Да, есть еще joyride. API неплох, да, но многие вещи гвоздями прибиты и всего не настроишь.
Наверное, основной вопрос в плане конфигурации VS Code по сравнению с
Emacs в том, что для Emacs можно было не особо переключаясь из
контекста текущей деятельности быстренько перейти в .emacs, что-то там
подправить и вернуться к основной задаче. В VS Code флоу совсем иной. Если ты
вдруг понял, что тебе нужно что-то доконфигурировать, ты понимаешь,
что либо на это нужно просто забить, либо мысленно сказать что-то
вроде, «ну что ж, а теперь девочки и мальчики мы все бросаем и
осваиваем/вспоминаем специальность «конфигуратор/плагинописатель» для
VS Code», ибо быстренько что-то подхачить там не выйдет. Например,
тебе дополнительно нужен инстанс среды для тестирования изменений
плагина. Плагин дописывается, отлаживается и потом устанавливается в
рабочую среду. Если же, ко всему прочему, это не твой плагин (что
почти всегда), то нужно понимать, что вникать придется долго, ибо
комментариев и докстрингов нет примерно никогда (за исключением собственно
описания API от Microsoft).
При этом, всегда надеяться на то, что все будет «просто работать» нельзя. У меня например, после очередного обновления как-то отваливалась Calva (Clojure IDE) и edamagit (Magit for VSCode). Опять же, в Emacs у меня тоже были случаи, когда достаточно мейнстримовые плагины приходили с ошибками после очередного обновления. И в этой ситуации всегда можно быстренько это на лету починить, зарепортить багу или сразу прислать пулрек мейнтейнеру.
По итогу, решил попробовать NeoVim, ибо тоже в теории гибкая расширяемая среда, да и вообще, интересно и полезно из бочки вылезти, посмотреть, что в мире вимеров происходит.
Плюсы:
- Производительность UI, для чего делаются отдельно UI клиенты. Я по итогу выбрал neovim-qt
- Производительность Lua. Чуть хуже, чем JavaScript, но сильно лучше EmacsLisp. Впрочем, про производительность UI на относительно больших файлах будет ниже оговорка.
- Fennel - Lisp, работающий на Lua прекрасен. Это дает в чем-то схожий флоу конфигурации, что и в Emacs, когда поведение меняется на лету (см. подробнее: conjure)
- Сопоставимая с Emacs экосистема. Например, Magit (для Emacs), Edamagit (для VSCode) и NeoGit (для NeoVim) работают почти одинаково.
Минусы:
- Модальность. Для кого-то это плюс, я ее не люблю. Я настраивал конфигурацию без модальности. Но тут периодически натыкаешься на ограничение возможностей Vim по тонкой настройке.
- Менее удобная работа с Fennel, чем то, что предоставляет Emacs для EmacsLisp. На самом деле, они, конечно, не сопоставимы. Т.е. NeoVim не может быть такой же удобной IDE для Fennel как Emacs для EmacsLisp, уже по причине невозможности такой же интроспекции.
- Довольно причудливый API, многие вещи прибиты гвоздями еще со времен царя-гороха. Например, для некоторой функциональности нет полноценных функций, которые можно было бы вызвать через API, есть только хоткеи, т.е. приходится эмулировать их нажатие для вызова этих функций. Ситуация прежде всего в NeoVim постепенно меняется к лучшему, но до API Emacs пропасть неизмеримых размеров.
Но вот то, что реально заставило меня отказаться от пути использовать NeoVim и планомерно конфигурировать его в соответствии со своими предпочтениями, это то, что на больших файлах он стал повисать прям конкретно на десятки секунд. В Neovim Qt это очень сильно сказывалось. В Neovide лучше, но там нет антиалиасинга. А хотелось бы. В консольной версии аналогично. Отключил все плагины - ситуация не сильно поменялась. И максимальным шоком стало то, что Emacs с этим файлом спокойно работал. Подвисал, да, но на доли секунд.
Про Lapce и Helix, наверное, пока говорить рано, они довольно экспериментальные еще.
В общем, лучше Emacs пока никто ничего не придумал, хотя есть интересные попытки.
