[О блоге]
[наверх]
[пред]
[2022-07-03 21:06:33+03:00]
[1663d9d463041807b70067497fe45249e45b7755]
Темы: [vim]
vim9script vs Neovim
Спросили меня тут про vim9script:
Мне кажется, что это сложный и отчасти тупиковый путь. В таком
контексте Lisp (и конкретно ELisp) в Emacs выглядит как изначально
более рациональное решение. Смотрел ли ты в сторону neovim с его упором
на поддержку Lua?
И вот мои мысли на этот счёт:
Меня тоже посещали аналогичные мысли, когда я впервые услышал про то,
что в Vim пилят новый язык. Поддержка других языков, кроме vimscript,
была давным давно: видел/использовал плагины на Perl и Python. Но их
использование было связано в первую очередь, насколько мне запомнилось,
банально отсутствием асинхронных задач в Vim. С их появлением в Vim8, я
больше плагинов не на vimscript уже не встречал. Я писал когда-то их на
Python, так как он был и основным рабочим языком у меня, но позже как-то
само собой всё переписалось на vimscript.
Мне кажется что неявная killer-feature программирования на vimscript это
то, что ты постоянно находится в экосистеме редактора. У тебя идёт не
кусок кода на Perl/Python/Lua/Tcl/whatever, а потом внезапный вызов
vim.run("kj$R$3lrk4r") абракадабры интерактивного ввода, а ты пишешь на
языке в котором прямо в его скрипте можно написать "normal gg:%d"
какой-нибудь. Когда пишешь "mark '", "@/ = 'pattern'", "execute smth",
то все его задействованные переменные, метки и регистры являются родными
объектами редактора. Вместо программирования на чём-то в интерпретаторе,
делая API вызовы к редактору, ты находишься в контексте редактора
постоянно. Всё это позволяет прямо мгновенно на коленке взять и писать
себе скрипт для какой-нибудь автоматизации. Не полноценную программу на
настоящем большом языке, делая API вызовы к редактору, а именно писать
внутри редактора. Не знаю как корректнее выразиться, но это всё прям на
ощущениях.
И поэтому у меня давным давно не возникает применять что-то кроме
vimscript для скриптования Vim-а. Vimscript пускай и странен, и некрасив
и уродлив местами (всякие странные переносы, "call"-ы например), но по
возможностям он вполне себе предоставляет кучу всего (словари, списки,
лямбды, даже методы -- не существенно отличаясь от всяких более
привычных Python/JavaScript/Lua). Для знакомых с Py/JS -- в vimscript
очень небольшой порог входа и куда более тесная интеграция с редактором.
Я думаю поэтому и не приживаются его плагины на сторонних языках,
особенно после появления асинхронных задач в Vim8. Я писал на Python,
думал что это точно будет удобнее, ведь я и вне редактора его
использовал, но положительных воспоминаний у меня не осталось, хотя по
сути там точно такие же "normal ..." вызовы можно было делать например,
но не чувствовался profit от неиспользования vimscript-а.
Касательно Neovim: я пробовал его использовать с разницей в года. Каждый
раз у него было другое поведение, какая-то несовместимость. Это выбивает
из колеи и раздражает -- ведь ожидал я прозрачной незаметной смены
редактора.
Что он мне дал бы дополнительного, как пользователю редактора? Я знаю
только про встроенный LSP клиент. В Vim-е это был бы вопрос одного
плагина. More sane defaults -- слишком субъективно, да и какая разница
будет ли на пару строк больше/меньше в .vimrc? Всё равно без
персонифицированного .vimrc не обойтись.
То есть, Neovim должен иметь какую-то крутую killer-feature чтобы
переход на него (прозрачно у меня не вышло ни разу -- он не полностью
обратно совместим) стоил того. LSP не является такой feature. Может быть
Lua как альтернатива vimscript? Просто Lua можно было и прежде
использовать в Vim. Причины того, что сторонние языки не приживаются я
описал (как мне они видятся). В Neovim это мог бы быть luajit с
увеличенной производительностью. Пока это единственная возможная
killer-feature.
Которая теперь полностью нивелируется vim9script. В случае с Neovim мне
надо бы было полностью на другом языке переписать свои плагины. Это не
малая работа. И изучать этот новый язык Lua (лично я на нём год писал,
мне он нравится, но многие никогда с ним не пересекались). В случае с
vim9script, "конвертация" vimscript в vim9script -- небольшая работа.
Этот новый язык не отличается кардинально от старого. Плюс ещё более
дружелюбен к тем, кто писал на Py/Lua/JS/whatever. Переделать vimscript
на vim9script -- существенно менее трудозатратно, при этом, как заверяет
Брэм (ну и другие люди в рассылке), можешь получить ускорение на
порядки.
В итоге: трудозатрат на порядки меньше, профит в производительности
получишь. И опять у Neovim не выходит ни одной killer-feature стоящей
рассмотрению перехода на него. Ну и я не забуду что Vim собирался на
старом ноутбуке за пару минут, а Neovim -- пару часов, что не очень
приятно (хотя я и понимаю что не каждый день этим занимаешься). Меня не
очень привлекают решения разработчиков Neovim: если Lua это вполне себе
хорошее решение (в вакууме для произвольного редактора), то MessagePack
совершенно не ясен, как будто это какой-то highload проект.
От vimscript в Neovim не избавиться: так как написаны тысячи плагинов на
нём. Смысла переписывать хотя бы часто используемые (surround, fugitive
какие-нибудь) -- никто не нашёл. Сейчас их переделать под vim9script и
они ещё и быстрее станут. А как язык, vim9script ещё ближе стал к
привычным современным Py/JS.
Не исключено что я просто так сильно привык к vimscript что мне он
заходит и мне с ним легко. Но вот Neovim сколько не существует, но не
смог заинтересовать ничем, что не требовало бы приличных трудозатрат без
ясного понимания нафига это надо. А Брэм (и команда) придумали нечто,
благодаря чему можно без существенных затрат всё ещё сделать красивее и
удобнее (с точки зрения программирования) и без тормозов. Почти бесплатно.
Помнится что у Neovim изначально была killer-feature в виде асинхронных
задач. На нём можно было писать любую асинхронщину на Lua. Но Брэм
сделал асинхронные задачи в Vim8, которые оказались гораздо удобнее для
использования и очень простые.
Vim на протяжении всей своей истории демонстрировал что Брэму нужен
пинок под зад. Регулярно nvi что-то вкусное изобретал, становился неким
конкурентном с killer-feature, но в Vim впиливали похожу штуку которая
была зачастую лучше/проще/яснее. Огромная ценность Neovim в том, что он
был пинком для создания асинхронных задач в Vim8, ещё какого-то
функционала (типа balloon-ов и popup-ов, lambda, packages, если не
придумываю). И вот он был пинком для создания очень простой (с точки
зрения порога входа) vim9script, который, такие как я, сразу же рвутся
попробовать и быть им довольным.
Колоссальная ценность Vim-а же ещё в его плагинах. Если потеряется с
ними совместимость, то задаёшься вопросом "а нафига мне это тогда
надо?". Редактор в котором не будет аналога surround/repeat/abolish мне
не нужно. Писать это с нуля? Даже не могу представить какая killer
feature в редакторе могла бы появится чтобы заставила меня пойти на это.
А Брэм даёт возможность развивать и улучшать свой experience новыми
фичами, не ломая уже рабочие мощнейшие отлаженные инструменты (плагины).
Neovim говорит ещё о более чистом API, возможности использования разных
GUI, встраивания в броузеры и IDE. Возможно разрабатывать сам Neovim
существенно удобнее и проще. Возможно (легко поверю!) Lua внутри него
существенно помогает. Но конечного profit-а для меня, как пользователя
это не даёт никакого. Был бы разработчиком инструмента (редактора), то
наверное бы это играло роль. А как конечный пользователь меня не
интересует насколько там красивее и проще внутри Neovim-а всё, если я
при этом не вижу чтобы на всём этом появлялись полезные мне killer
feature. Это как бы внутренняя кухня, меня не затрагивающая.
[оставить комментарий]