По большому счету единственной незакрытой темой в рубрике "Про Vim" осталась тема об альтернативе Conqueror of Completion для Neovim в Lua исполнении. Причиной перерыва между данной и предыдущей статьей в рубрике стало отсутствие необходимости в этой самой альтернативе. Ну или вернее причина может быть и была: во-первых - что бы удовлетворить любопытство, во-вторых - CoC действительно кажется громоздким и достаточно сложным внутри. Вариант на Lua мне бы дался легче, если бы захотелось что-то в нем подшаманить. Наверное.

Чем проще и очевиднее исходный код, тем автор более продвинут. Казалось бы, об этом твердят уже на протяжении полувека светлейшие головы индустрии, но складывается такое ощущение, что далеко не все согласны с этим утверждением. Появились разнообразные инструменты и методики программирования, которые буквально силком заставляют очередного джуна следовать заветам аксакалов, но джун как будто сопротивляется изо всех сил, пытаясь как можно дальше уйти от предлагаемых идей.

Я могу тут судить только по себе, возвращаясь к собственному становлению и личным ощущениям. Однако, в те далекие времена, когда джуном бы я, мало кто слышал про паттерны и рефакторинг. Но красивый и понятный код был всегда. Были книжки с листингами программ, были исходные коды открытых библиотек и фреймворков. Я тогда недоумевал, почему реальный код, даже написанный, в серьезных, по тогдашним меркам, отечественных организаций, настолько сильно отличается от образцового. Наверное, предполагал я, что напоказ люди пишут один код, а в свободное от написания умных книжек время садятся за компьютер и что-то очень непонятное, но как-то значительно лучше работающее.

Когда же код, написанный личной мной, начал попадать в бой и к коллегам, то стало понятно, что код то в основном пишут как раз не те люди, которые публикуют книги и статьи, а вот такие джуны. Средний кодер любого, сколь угодного крупного и серьезного проекта по определению джун. Их просто больше. Да, где-то мельком встречаются кусочки написанные более опытными товарищами, но их откровенно мало и они то чаще всего и представляют из себя скорее какие-нибудь библиотечки и фреймворки - не бизнес логика, не конкретные реализации и не все эти кошмарные базы данных.

Краткий отчет по результатам.

Сообщают, что льготной ипотекой воспользовалось несколько тысяч специалистов по всей стране. Много это или мало оценивать не возьмусь, но в паре крупных банков, не будем упоминать конкретных наименований, к моему заявлению отнеслись весьма озадаченно. Может операционисты попадались такие, может еще что-то, тем не менее пришлось неоднократно объяснять, что в их банке действительно есть такой ипотечный продукт и что он вроде как должен действовать.

На какой-то момент закрались сомнения, что прошлогодние анонсы так и не дошли толком до реализации. Оказалось зря - во многих банках, хоть некоторые операционисты об этом и не в курсе, программа работает и заявку в итоге приняли и одобрили. Процедура подачи и одобрения стандартная, смотрят трудовую, зарплату за последний год и в общем без каких-то дополнительных проверок. Наверное где-то внутрях сверяют организацию с реестром, не знаю. На сроки отказа или одобрения тоже данное обстоятельство, надо понимать, никак не влияет.

Некоторые вопросы возникли после. Дополнительные условия и процентные ставки по разным банкам значительно отличаются. В одном это 4%, в другом - 5%, отличаются размеры первоначальных взносов и типы объектов доступных для покупки. Надо полагать, что квартиры в новостройках в крупном городе раздают без лишних вопросов. А вот с остальным всё интереснее. Дальше мой опыт сужается до одного конкретного банка, у которого получалась самая низкая ставка по первоначальному взносу. С возможностью купить отдельный жилой дом.

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

Смотрите, понятно, что всё зависит от позиции, должности, требований к квалификации. Нет одинаковых интервью, нет одинаковых интервьюеров. Однако цель то всегда одна - найти подходящего специалиста. А не выставить оценку в зачетной книжке, и уж тем более не поблистать собственным умом или самоутвердиться за счет кандидатов.

Опыт прохождения интервью у меня лично небольшой. Как-то так выходило, что меня до сих пор брали сразу. Может везло, может претензий у меня было меньше. Таким образом я не могу говорить за всех. С другой стороны, можно примерно догадываться о том, какие вопросы задают на технических собеседованиях по многочисленным роликам и шпаргалкам. Примерная суть разговоров понятна, и что важнее, она подтвердилась на примере пары известных организации. Более того есть разные статьи на данную тему, есть даже специальные люди, которые не безвозмездно натаскивают кандидатов.

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

В российском сегменте разработки программного обеспечения исторически сложилось так, что молодой разработчик подспудно считает, что программа написанная по заказу российской компании и для российского пользователя в принципе никогда не попадет в руки кого-нибудь за рубежом. Во многом это связано с предыдущей эпохой, когда связи с остальным миром были сильно нарушены по понятным причинам. Однако даже тогда почему-то считалось, что отечественное программное обеспечение это нечто непременно разговаривающее с пользователем исключительно по-русски. Хотя в то же время партнерами СССР были страны совершенно несвязанные с русской культурой и языком. Это наши некоторые юго-восточные союзники, страны Африки, Куба, Афганистан.

Если даже говорить о, пусть и близких, но все-таки не совсем русскоговорящих, партнерах в восточной Европе и балканских странах, то выяснится, что даже кириллицей пользуются совсем не многие из них. Поэтому лично мне не очень понятно почему ни кто наказывает программистов за принудительную русификацию программ. Ну, хорошо, есть совсем узкий круг задач для закрытых предприятий, решение которых вряд ли пригодится где-нибудь кроме российской федерации. С другой стороны, а как же, например, Белоруссия? Киргизия? Прости Тенгри, Монголия?

А как же в конце концов национальные языки внутри страны? Хорошо, может быть, для внутренней документации, исходной кодировки и форматов дат и чисел достаточно русского языка, но пользовательский интерфейс совершенно не обязан быть только на государственном. Может региональный сайт разговаривать с пользователем на местном языке? Запросто.

Продолжая разговор о математике для программиста предлагаю еще одну провокационную мысль относительно спорной идеи о том, что программирование - творчество или искусство. Заранее обращаю внимание читателя на то, что это не исследование или утверждение, а некая попытка подвести итог под имеющимися мнениями разных авторов. Которые, к слову, делают радикально противоположные выводы из своих суждений. Начиная с того что программирование это вершина творческой мысли, заканчивая тем что программиста легко заменить машиной.

Всегда забавляют разные формулировки на тему нужна ли программисту математика. Учитывая что алгоритмы и логика, собственно и есть математика в самой её основе, тут впору поставить вопрос о том, что является первичным для современной математики: арифметика, алгебра и геометрия или алгоритмы и логика. Программист, как специалист по применению алгоритмов и логики, есть математик. А математик, в каком-то смысле, и есть программист. Нужна ли математика математику?

Другое дело вопрос: что имеется ввиду нынче под "математикой для программиста"? Или какие разделы математики актуальны нынче в институтах по специальностям связанным с программированием? Чем в итоге чаще всего придется пользоваться? В каких специализациях? Об этом хотелось бы и повторить.

Теоретически если вы решили пересесть с классического Vim на более современный его клон - Neovim - вам делать ничего особенного не надо. В файле ~/.config/nvim/init.vim прописать source ~/.vimrc ну и скачать или скопировать словари. Идея в том, что Neovim должен поддерживать все конфигурации Vim по умолчанию. Однако, если у вас установлено множество плагинов и разных к ним расширений, то с высокой вероятностью конфигурация загрузится с ошибками, предупреждениями и другими, не очень желательными нюансами. Да и вообще вся фишка, вся разница Neovim заключается в том, что он поддерживает настройки и плагины написанные на Lua вместо vimscript.

Lua - более современный интерпретируемый язык, на нем удобнее писать, его проще читать. А еще, считается, что работает интерпретатор на порядок быстрее родного языка. На счет порядка я бы засомневался, но действительно тяжелые плагины работают вроде как расторопнее и глаже. Впрочем и классический Vim известен не тем, что он медленный или глючный, так что тут спор скорее софистический. А вот с первыми тремя утверждениями я абсолютно согласен.

Более того для Neovim именно на Lua в последнее время выбор современных плагинов и расширений, что уж тут говорить, куда богаче. Вопрос даже не в том лучше ли эти аналоги, а в скорее в свежести, динамике развития и в целом в оптимизме сообщества. Очень похоже на то, что не сегодня так завтра Neovim повторит судьбу предшественника и займет свое место в распространенных дистрибутивах Linux в качестве стандартной замены устаревшему Vim. Заменит полностью? Ну, я бы не был так категоричен в этом вопросе, но вероятность такая существует.

После пары месяцев использования тайлинговых менеджеров вернулся к кедам и плазме. Мой мир оказался не готов к столь радикальным переменам. Кто-то скажет что я недостаточно старался - может быть. Но есть и, на мой взгляд, объективные причины.

Только ленивый не отписался о прелестях ChatGPT, и я, соответственно, как человек не самый ленивый тоже должен что-нибудь сказать по этому поводу. С другой стороны, о волшебных свойствах современных нейронных сетей говорится как-то однобоко - в ключе, что никогда такого не было, и вот опять. У меня не то что бы своя точка зрения на эту тему, и не то что бы свежая, но почему-то мало озвучиваемая.

Оглядываясь вокруг нельзя не заметить, что отношение отечественных разработчиков к результатам собственного труда довольно сильно отличается от того чем руководствуются западные их коллеги. Меня могут заклевать за то о чем я буду говорить ниже отдельные прошаренные экземпляры, но речь здесь не о них, а как и заявлено в названии рубрики, о начинающих, о вчерашних студентах, о ребятах, по ушам которых не так давно поездили в отделе кадров. И о том как им начать думать о себе не как о простом маленьком человечке среди прожженных опытом знатоков, а как о самостоятельном субъекте гражданского права, и, как следствие, права авторского.

Потому что правовая подготовка, даже базовая, как правило у обозначенных опытных товарищей так же отсутствует. Более того нередки случаи, когда и у руководства в том числе юридического, не в всё с этим в порядке. Укоренившаяся стандартная мантра из уст таких деятелей звучит примерно следующим образом: “Ты работаешь по трудовому договору, в котором прописаны твои должностные инструкции, по которым ты в рабочее время на рабочем месте разрабатываешь ПО. Которое потом таким образом автоматически становится собственностью работодателя”. Некоторые, чуть более прошаренные, при этом ссылаются на технические задания и некие исключительные права, которыми, опять же, якобы автоматически обладает работодатель.

И это выглядит на первый взгляд настолько убедительно, что у нового наемного работника даже не возникает нотки подозрения, что здесь что-то не так. И почему на западе так носятся со всякими патентами, судами, авторскими отчислениями и прочим юридическим балластом. Часто приходится слышать и аргумент в пользу того, что наше законодательство дескать отличается от, скажем, американского, и по этому это их американские заморочки. Да и вообще кто ты такой, что бы ставить под сомнение профессиональную пригодность целого юридического отдела?

Говоря о профессиональном программировании на Java нельзя не отметить, что усредненные сценарии применения несколько отличаются от ранее рассмотренных баз данных и PHP. Разработка будь то бекэнда или мобильных приложений на Java или под JVM всё-таки связана с промышленными и крупными проектами, для которых важна стабильность, быстродействие, кроссплатформеность и прочие плюшки получаемые в комплекте. Не пишут лендинги или отчеты на Java в заметных количествах - на Java, как правило, написаны серьезные системы под руководством крупных компаний не имеющих острого дефицита в финансовых ресурсах. В экосистеме Java cложилась ситуация даже, с некоторой точки зрения, обратная PHP, у которой средства разработки в основном коммерческие, а продукты малопригодные к тиражированию и нужные только владельцам некоторого основного бизнеса. В мире же Java недостатка в бесплатном и довольно качественном инструментарии как будто и нет, но для профессиональных разработчиков нет проблем с тем что бы и приобрести замечательные коммерческие продукты производства JetBrains или специализированные инструменты типа PWS Studio.

Поэтому сценариев когда во что бы то ни стало надо использовать бесплатные инструменты мало. С предложением разработать какой-нибудь продукт на платформе Java скорее всего выйдет какой-нибудь крупный заказчик у которого не возникнет вопросов с предоставлением вам рабочего места или каких-то лицензионных продуктов. Либо вам предложат такую сумму, которая будет подразумевать сопутствующие расходы. Вряд ли, если вы опытный Java разработчик, и у вас есть проблемы с личным оборудованием, которое не потянет последнюю редакцию IntelliJ Idea или Eclipse JDT. Но, да, это если вы действительно опытный специалист.

Проекты PHP в данный момент у меня заморожены или переданы коллегам, поэтому толком попрактиковаться в Vim пока особенно не получается. Тем не менее есть что обозначить и пусть данная заметка будет эдаким введением в проблематику. Если на первый взгляд кажется что её нет и вовсе - проблематики, то на второй взгляд становится понятно, что не всё так однозначно и просто, примерно так же как и с базами данных.

Если загуглить "vim php lsp" то с высокой вероятностью вы попадете на проект Intelephence и плагины его использующие. Который платный. Вообще удивительно, но вокруг в общем-то опенсорсного PHP многие компании, с упорством достойным лучшего применения, пытаются создать платную инфраструктуру. Является ли при этом PHP Group каким-то бенефициаром такого положения вещей не совсем очевидно. Тем не менее воз и ныне там - кто только не разрабатывает инструментарий, только не сами авторы. И так сложилось, что лидерами в производстве инструментов являются наиболее жадные коммерческие компании как JetBrains и разработчики указанного Intelephence.

Если вы тот кто считает, что это правильно и нужно поддерживать поддерживать производителя рублем, если вы разработчик промышленных решений - нет проблем - к вашим услугам PhpStorm и Zend Studio. И в них правда нет ничего плохого. Более того, они действительно поддерживают всё и вся связанное с PHP причем самой последней версии. Но, знаете, городить огород с покупкой лицензий для эпизодической поддержки легаси кода, которого нынче значительно больше какого-то передового, мне лично не кажется целесообразным. Только вот с бесплатными инструментами всё несколько запутано.

Что чаще всего нужно программисту от форматирования? Расстановка отступов? Или может быть разбиение списков параметров по вертикали? Следование каким-то конвенциям стиля? А вот и нет. Мне, как программисту, жутко не хватает программы, которая бы расставляла за меня запятые. Ну, или удаляла оттуда там где их быть не должно. На данный момент я так понимаю, можно воспользоваться каким-нибудь онлайн-сервисом или, в лучшем случае, как-то подцепиться к API. Есть на этот счет пара вариантов типа https://text.ru/api-check, https://sinoni.men/ или https://languagetool.org/ru/.

Однако, понятно, это всё ограничено и недешево. Да и это скорее эдакие линтеры, которые могут достаточно хорошо предположить и указать на явные ошибки. Про линтеры отдельный разговор. Вот бы было здорово сделать локальный LSP сервер для русского языка? Как вам идея для стартапа? Я провел достаточно много времени с экспериментами над грамматическим и морфологическим разбором предложений на русском языке. Была даже попытка прикоснуться к лингвистическим корпусам и нейронным сетям. Не могу сказать, что эксперименты закончились чем-то примечательным. Однако могу утверждать, что до определенной степени такую затею вполне можно воплотить даже в одного. Всё зависит лишь от желаемой точности и универсальности продукта. Если, положа руку на сердце, оценить, то как пишут даже вполне грамотные люди, то достичь уровня десятого класса средней школы уже было бы достижением. Если текст состоит не из помеси трех языков, топонимов, имен древнеегипетских богов и сложносочиненных оборотов, коих большинство, то каких-нибудь 90% точности при расстановке запятых и двоеточий хватило бы за глаза.

Существует три основных способа работы с базами данных. В первую очередь, это конечно же родной графический или веб интерфейс. Который, помимо прочего, разбирается как в устройстве СУБД, так и может на лету подгружать структуру текущей БД. Вряд ли кто-то не согласен с тем, что это наиболее удобный способ составления сложных запросов и процедур на целевом диалекте SQL. Да, и сегодня речь конкретно о реляционных БД.

Второй, не менее распространенный способ, это использование, опять же, графического клиента большой комплексной IDE. Отличие заключается в том, что встроенный клиент IDE, как правило, более универсален, использует либо какую-то внешнюю библиотеку-драйвер, и тем самым может быть несколько ограничен возможностями этой библиотеки или степенью поддержки специфических функций. Надо сказать, современные IDE это отличие максимально пытаются нивелировать. Так что для каких-то не самых сложных задач такой способ тоже достаточно оправдан и популярен.

Однако есть и третий сценарий. Это работа с клиентским консольным приложением и вынесенными в файлы скриптами или исходными кодами запросов и объектов БД. Вариант относительно не частый, но он существует. Более того, с внедрением автоматизированных конвейеров развертывания приложений нынче реализуется всё чаще. Современное приложение должно быть способно не только единожды устанавливаться на статическую БД, но и автоматически разворачиваться в виртуальных средах, обновляться и контролировать собственную целостность.

До какой-то степени работать с отдельными файлами можно и при помощи графических клиентов, но это, как правило, довольно таки избыточный процесс - графические средства предназначены всё-таки больше для редактирования объектов и данных в БД "напрямую". Да, в итоге это всё-равно текстовые запросы, но средства отображения и редактирования заточены именно под визуальное взаимодействие. Скрипты же для развертывания и обновления чаще всего не интерактивные и не нуждаются в каком-то форматировании вывода. Естественным образом возникает необходимость в некоем "оперативном" редакторе, который бы запускался быстро и при этом имел какие-то минимальные средства подсветки синтаксиса, автоматического дополнения ключевых слов, форматирования и даже непосредственного исполнения и отладки.

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

Необходимо немного поговорить о способе размещения конфигураций. Существует два радикально противоположных подхода к способу размещения конфигурационных файлов Vim. Одни аккуратно разбивают конфигурацию на несколько файлов и кладут их в разные места, оставляя в основном файле .vimrc только вызовы :source. Это то как бы поступил адекватный программист. Другие не считают конфигурацию Vim настолько серьезным предприятием и советуют класть всё в кучу, поделив настройки лишь на некие логические секции. Общее мнение - не набивать конфигурацию совсем рандомно.

Я бы наверное изначально поступил первым способом и разложил бы всё по неким "модулям", однако с Vim не всё так просто. Дело в том, что различные расширения подгружаются в редактор последовательно и более того часто взаимодействуют друг с другом - зависят друг от дружки. То есть придумать способ организовать файлы, когда в одном месте у нас только горячие клавиши, в другом цветовая схема, по большому счету нельзя. Каждый плагин отдельно будет иметь свои горячие клавиши, возможно какие-то тонкие настройки цвета, интеграцию с другими плагинами.

Кроме этого, в Vim встроены плагин, который подгружает дополнительные конфигурации в зависимости от типа файла (ftplugin). Что делает картину еще более не очевидной. Другими словами, разбивая конфигурацию на отдельные файлы велик риск наоборот только запутать себя. Поэтому предлагаю еще один компромисс.

В основной файл .vimrc я положил только то что будет работать практически в любом случае в любом окружении. И в конце подгрузил ~/.vim/plugins.vim в котором всё то что касается расширений. То есть всё что в директории .vim можно безопасно отключить в любой момент. Внутри же максимально попытался разделить файл на секции с комментариями по которым потом можно будет найти интересующий плагин или его конкретные настройки.

В предыдущем посте про горячие клавиши был сделан вывод о том, что лучше не трогать родные горячие клавиши и сочетания с модификатором CTRL и освоить их как есть, а все пользовательские команды и управление плагинами оставить на сочетания с клавишей лидером. Их туда можно напихать можно сколько угодно. Мнемонически это выгодно тем, что базовые сочетания будут работать везде и вы знаете, что сочетания с лидером могу работать каждый раз немного по-разному, особенно если вы активно используете конфигурации под определенные типы файлов (:filetype on). В каком-то случае LSP (Language Server Protocol) нужен, в каком-то нет, где-то DAP (Debug Adapter Protocol) работает, где-то в нем нет смысла, для большинства типов файлов омни автодополнение включено, для SQL скриптов лучше вызывать его вручную и так далее.

Однако всё это хозяйство работает пока не включен режим вставки. В режиме вставки остается очень ограниченный перечень плюшек, работающих с нажатым CTRL. Большинство пользователей при этом дружно сходятся во мнении, что в данном случае нужно беспрекословно следовать той самой философии "модального" режима, а именно: режим вставки - только для вставки. То есть встали на нужное место, нажали один из вариантов входа в режим вставки, кстати их там вагон и маленькая тележка, набрали нужный кусочек текста, и тут же вернулись в нормальный режим. "Нормальный" он именно поэтому - другие режимы считаются "ненормальными". Так вот? к этой философии привыкнуть после пары десятков лет с WYSWIG с разбегу, прямо скажем, сложновато.

Тема очень обширная, не сказать бесконечная, но я постараюсь затронуть только очень важные вещи, о которых говорится не так много в бесчисленных джентльменских минимумах по Vim. Хотя, конечно, придется время от времени возвращаться к теме дабы дать уточняющие указания или рекомендации. Да и не упомню я всего сразу. Память вообще штука интересная. Помнит ли человек как надо ходить? Раз кто-то забывает, то видимо помнит осознанно и не так уж что бы очень хорошо. Вроде как, через примерно пол года в постели или в космосе учиться ходить нужно заново.

В частности, видимо, с этим связано то, что во многих обучающих материалах так много говорится о повторяющихся вещах типа того как удобно использовать числовой префикс перед движением или командой, или о том как работают сокращения переходов по словам (w и b), по предложениям (( и )), по параграфам ({ и }), или о том как передвигаться по всему тексту при помощи <C-u> и <C-d> или <C-f> и <C-b>. И в то же время совсем мало говорится, например, почему-то о том как передвигаться в режиме вставки. Или, например, я совсем недавно открыл для себя замечательные f и F. Я смею предположить, что большинство тех, кто занимается составлением таких мануалов попросту перестают замечать какие-то движения, которые они сами используют уже на уровне рефлексов, а поэтому и не могут вспомнить когда составляют какие-то планы и даже когда непосредственно набирают текст.

Поэтому, я решил поимпровизировать: никакого предварительного плана. Сразу с точки зрения человека, который вот прямо сейчас сталкивается с какими-то особенностями, нюансами. Проверяя всё описываемое на ходу, используя вот этот самый текст. Надеюсь, именно это придаст данному материалу больше пользы, применимости что ли. С другой стороны, я осознаю, что от этого повествование может оказаться сумбурным, несвязным, и, местами, уходить куда-то в бок, сильно вперед или повторять, что-то старое. Тем не менее, начнем, таки с совсем простого - с движений.

Очередную рубрику в Одиночной палате решено начать на Хабре, так как дожидаться адекватного отображения исходного кода на Дзене не представляется возможным (неужели это так сложно). А в этой рубрике без примеров кода, судя по всему, никак.

Речь в рубрике пойдет о работе в текстовом редакторе (Neo)Vim в качестве разработчика и, местами, графомана. Но не в традиционных форматах хвалебных од, рейтингов лучших плагинов, пятиминутных гайдов или хауту, а в формате неких мемуаров что-ли. От лица начинающего, а затем и более продвинутого, пользователя - часто от первого лица. Так как считаю, что категорически не хватает именно чего-то среднего, чуть более применимого в реальной жизни и работе, чем ролики в ютубе с пересказами "Getting started with..." на разный манер, и чуть менее объемного и перегруженного чем полные руководства. Так же крайне мало информации конкретно для русскоязычных пользователей и особенностях работы с раскладками отличными от латиницы.

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