Что: 1663d9d463041807b70067497fe45249e45b7755 Когда: 2022-07-03 21:06:33+03:00 ------------------------------------------------------------------------ Темы: 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. Это как бы внутренняя кухня, меня не затрагивающая. ------------------------------------------------------------------------ оставить комментарий: mailto:comment@blog.stargrave.org?subject=Re:%20vim9script%20vs%20Neovim%20%281663d9d463041807b70067497fe45249e45b7755%29 ------------------------------------------------------------------------ Сгенерирован: SGBlog 0.34.0