Моя история не редкость. В начале учебы в колледже я посещал занятия, на которых
профессор рассказывал о том, о чем я никогда не слышал, — о редакторе по имени Вим.

Как будто VSCode поставил мне ультиматум: «Это я… или Vim».

Сначала я был заинтригован. Из невинного любопытства я начал баловаться. Конечно, поначалу я был ужасен, но гордился каждым сделанным маленьким шагом. Я
стал увереннее, зная, что могу подключиться к удаленному серверу по SSH и редактировать файлы
, не потерявшись полностью. Конечно, я по-прежнему тянулся бы к клавишам со стрелками
вместо hjkl и иногда застревал в режиме Ex (честно говоря, я до сих пор
не знаю, как выйти из режима Ex). Постепенно я улучшался, но не был готов к долгосрочным обязательствам.

Примерно в это же время я был в отношениях с Atom, когда мое внимание привлек этот новый яркий текстовый редактор — Visual Studio Code. У него были хорошие связи, и он происходил из богатой компании. Отказ от Atom был легким выбором.

В начале все было замечательно. Однако со временем чувства переросли в платонические. Я продолжал спрашивать себя, правильно ли я принял решение. Но знаете, мы просто… работали. VSCode был безопасным, знакомым и создавал ощущение стабильности.

В конце концов, я закончил колледж и начал свою карьеру. Время от времени я сталкивался со своим старым другом Вимом, и старые чувства всплывали на поверхность. Я не знаю, была ли это просто скука или осознание того, что VSCode не позволяет мне проявить себя с лучшей стороны, но я начал заигрывать с идеей использовать Vim в качестве текстового редактора на постоянной основе.

К сожалению, как бы ни болело запястье, это было слишком тяжело. К этому моменту у нас с VSCode уже было несколько совместных проектов. Знаете, дело было не только во мне! Конечно, я установил расширение Vim в VSCode, но от этого стало только хуже. Чем больше я узнавал Vim, тем больше он мне был нужен. Как я мог игнорировать возросшую производительность и удовлетворение, которое я чувствовал как разработчик? Маслянистые плавные нажатия клавиш заставили меня снова почувствовать себя живым, когда я просматривал свой редактор. Вскоре я понял, что пути назад нет. Я чувствовал себя застрявшим между двумя мирами: VSCode, с одной стороны, и Vim как расширение, с другой. У меня была двойная жизнь, и я мог сказать, что Вим не чувствовал, что это место. Это было почти как хозяйка, живущая в доме, который, как она знает, на самом деле ей не принадлежит. Ха, я увлекся, такая глупая аналогия.

Я чувствовал себя застрявшим между двумя мирами, VSCode с одной стороны и Vim с другой. У меня была двойная жизнь, и я мог сказать, что Вим не чувствовал, что это место.

Прошло время, и я начал думать, что все может получиться. Но, по воле случая, меня неожиданно поставили на большой проект Typescript. Шучу, проект был даже не таким уж большим. Тем не менее, из ниоткуда VSCode начал сильно страдать. Постоянный линтинг, автоматическое форматирование, наблюдатели за файлами и работающая диагностика кода стали слишком сложными для VSCode.

Такого рода вещи случались в какой-то степени раньше. Я заметил, что VSCode проводит все больше и больше времени с Code Helper (Renderer). Я чувствовал себя отчужденным, и мы, казалось, становились все дальше и дальше друг от друга. Но я должен был поддерживать статус-кво, поэтому я сделал все, что мог, чтобы мы продолжали работать.

Ультиматум

Другие предупреждали меня о возможных проблемах с производительностью VSCode, и, поверьте мне, у меня были свои подозрения. Тем не менее, я никогда не думал, что это произойдет со мной. Для меня! Я пытался отключить другие расширения в надежде что-то исправить, но в итоге вышло именно так, как я и опасался. Большая часть проблем с производительностью связана с моими отношениями с Vim.Как будто VSCode поставила мне ультиматум: «Это я… или Vim».

И поэтому я последовал своему сердцу и оставил VSCode.

Это было сложно. Были трудные дни. Иногда у меня возникало искушение вернуться к
знакомому VSCode. Но я закончил с обустройством.

Я был полностью предан этой новой жизни, но не мог отрицать, что VSCode изменил меня. Я понял, что для меня важнее всего просто иметь работающий редактор. Даже по сей день я все еще борюсь с этим.

Суть Вима

Помимо сатиры, вхождение в мир Vim чрезвычайно сложно для непосвященных. Vim имеет свой собственный набор компромиссов, в основном в виде больших первоначальных затрат, оплачиваемых в валюте времени. Но просто понимания Vim недостаточно. Вы могли бы знать справочные документы от и до. Вы можете узнать разницу между различными режимами, включая вставку, нормальный, визуальный, визуальный блок, визуальную строку, выбор, выбор строки, выбор блока, завершение вставки, вставку визуального элемента, вставку визуальной строки, вставку визуального блока, вставку выбора, вставку выбора line, вставить блок выбора, заменить и виртуальные режимы замены (я что-то пропустил?!?!). Вы можете знать все о Vimscript или быть мастером в Lua.На самом деле, вы можете отлично понимать Vim и при этом быть совершенно бесполезным.

Вы можете прекрасно понимать Vim и при этом быть совершенно бесполезными.

Почему? Потому что эффективность в Vim достигается за счет повторного выполнения одних и тех же действий до тех пор, пока они не станут автоматическими. В буквальном смысле вы должны стать Vim. Это знание хранится в теле, а не в уме. В этом суть Vim. Вы просто думаете о том, чего хотите, и это происходит автоматически. Но, боже мой, нужно время, чтобы добраться туда.

В буквальном смысле вы должны стать Vim. Это знание хранится в теле, а не в уме. В этом суть Vim.

Я больше не считаю VSCode достойной альтернативой для себя. Это, в конце концов,
личное путешествие. Тем не менее, с другой стороны, требуются часы настройки
Vim, чтобы довести его возможности до паритета с VSCode. И после того, как конфигурация выполнена, требуется еще больше часов тренировки мышечной памяти, прежде чем обещание повышения производительности осуществится. И это еще не конец! Часто я обнаруживаю новый плагин, который решает проблему, о которой я не знал, или имеет превосходный рабочий процесс, который мне нужно принять, возвращая меня к исходной точке.

В сторону: К счастью, Neovim избавляет от некоторых проблем с настройкой. Поскольку основная команда Neovim продолжает добавлять поддержку Lua, я подозреваю, что ситуация будет только улучшаться.

В культуре Vim существует мнение, что .vimrc/init.vim — это очень личное. Уникальность установки часто порождается чувством гордости и чем-то, что нужно праздновать. Мое личное мнение: это происходит естественным образом, когда люди собирают конфигурацию до тех пор, пока она, наконец, не заработает, что приводит к тому, что люди зацикливаются на том, является ли , или <space> старшим ключом лидера, или следует ли вам использовать Ctrl-c или набирать jk в быстрой последовательности. чтобы выйти из режима вставки. В Vimland трудно найти согласованность, когда каждая возможная комбинация клавиш является потенциальным ярлыком. Это одна из самых сильных и слабых сторон Vim одновременно.

Когда кто-то публично делится своей конфигурацией Vim, это часто делается для вдохновения или получения инструкций. Для давних пользователей Vim использование чужой конфигурации означало бы серьезное нарушение их рабочего процесса. Новые пользователи Vim более склонны к полному «копированию-вставке» чужой
конфигурации, что приводит лишь к неоптимальной эффективности (я знаю, потому что был там). Это связано с тем, что новые виммеры не понимают и не учитывают, как автор пришел к определенной настройке, включая проблемы, которые он пытался решить, почему он выбрал свой конкретный набор плагинов, свой выбор сочетаний клавиш и так далее.

В качестве личного примера я только что обнаружил возможности Telescope, интегрированного с ripgrep, для передачи диагностики языка, предоставляемой null-ls/LSP, в список быстрых исправлений, чтобы я мог применить шаблон регулярного выражения с :cdo для предварительной формы поиска и замены в масштабе проекта.

Те, кто знаком с только что описанным рабочим процессом, говорят: "Отлично,
верно!" Давние пользователи Vim, которые не знакомы с одним или несколькими из упомянутых инструментов
, говорят: «Хм, звучит интересно, мне нужно узнать больше». Новые пользователи Vim говорят: «Вот что я ввязался?…», а пользователи VSCode говорят: «Вы сказали «найти и заменить»? Да нет. Я буду придерживаться
Ctrl+Shift+F». И я бы не стал их винить. Простите за обобщения, но настроение прямое.

Ну что теперь?

Упомянув описанный выше рабочий процесс поиска и замены, я с готовностью признаю, что пришел к нему не сам. Это произошло в результате Лунарвима.

Lunarvim — это «слой IDE для Neovim», который поставляется с хорошей коллекцией плагинов и нормальными настройками по умолчанию. Это стало передышкой, потому что я мог получить что-то прямо из коробки, на 100% родное для Vim, с (почти) всеми функциями, которые мне нужны в IDE.

NvChad — еще один преднастроенный редактор Neovim, который, как мне кажется, заслуживает почетного упоминания. Он (на момент написания) имеет больше звезд на Github, чем Lunarvim.

Исторически известно, что пользователи Vim/Neovim получают удовольствие от работы со своей конфигурацией. Я подозреваю, что растет число тех, кто хочет использовать Vim в качестве IDE, не утруждая себя настройкой каждого сантиметра своей среды.

Я чувствовал замешательство, пытаясь понять, какой менеджер плагинов использовать, почему их
так много, и чувствовал разочарование, что мне даже нужно было об этом заботиться. Я взял
Lua только для того, чтобы настроить Neovim. Да, это изящный маленький
язык. Нет, мне все равно.В конце концов, я использую Vim исключительно для того, чтобы
писать код максимально продуктивно и быстро. Изучение дополнительного языка (хотя и простого) просто для настройки моего редактора, чтобы я мог выполнять свою настоящую работу, является чертовски большим барьером!

Несмотря на то, что Lunarvim предоставила предварительно собранный Neovim, я все же обнаружил, что настраиваю опыт, который, естественно, включал в себя погружение в глубокие и пещеристые кроличьи норы. Это было не совсем то, что я бы назвал удобным для пользователя интерфейсом. Но это прогресс.

Подведение итогов

Это длинный пост, уже поздно, и я тяну, так что вот вкратце.

  • Я предвижу день, когда появится полнофункциональная нативная среда разработки Vim, которая просто работает и проста в настройке.
  • Vim уже достаточно сложен для изучения, не говоря уже о целой экосистеме плагинов. Хотя я полностью уважаю мастеров, некоторые из нас просто хотят перейти к той части, где кодирование происходит для нашей повседневной работы.
  • VSCode, несмотря на его плохую репутацию в сообществе Vim, имеет ценные уроки в области удобства использования и эргономичных интерфейсов.

По иронии судьбы, я думаю, пришло время научиться писать плагины Lua для Neovim и воплотить мечту в жизнь!