VIM *

Проекты 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 можно безопасно отключить в любой момент. Внутри же максимально попытался разделить файл на секции с комментариями по которым потом можно будет найти интересующий плагин или его конкретные настройки.

Навигация - визитная карточка Nvim. Мы можем молниеносно перемещаться по коду-тексту, не ограниченные скоростью мыши или человеческими возможностями. Говорят, что эксперименты Либета доказали, что человек сначала перемещается, а потом думает… В колдовском редакторе все будет именно так.

В предыдущем посте про горячие клавиши был сделан вывод о том, что лучше не трогать родные горячие клавиши и сочетания с модификатором 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. Я смею предположить, что большинство тех, кто занимается составлением таких мануалов попросту перестают замечать какие-то движения, которые они сами используют уже на уровне рефлексов, а поэтому и не могут вспомнить когда составляют какие-то планы и даже когда непосредственно набирают текст.

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

Режим в жизни нужен для того, чтобы не растолстеть к тридцати годам и высыпаться.

Режимы в Nvim нужны для того, чтобы сломать жизнь неподготовленным чародеям, а выспаться вы сможете только тогда, когда полностью прочитаете всю документацию, сможете выйти из Nvim и, просветленный, навсегда отключите компьютер…

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

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

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

Никто не любит конфиги (я уж точно). Они скучные и нединамичные.

Но со своим конфигом Nvim’а я ношусь, как Голлум с кольцом Всевластья. Моя прелесссссть. Я боюсь потерять свой конфиг, боюсь, что с ним что-то случится. Другие хотят забрать тебя, моя прелессссть. Саша тебя им не отдаст, нет-нет...

Если кто-то отнимет мой конфиг - я буду гнаться за ним до Роковой Горы и даже прыгну в жерло вулкана.

В этой статье я расскажу, как создать такой Конфиг Всевластья и как завоевать Гондор.

Nvim - это не обычный текстовый редактор, а программа, которая позволяет вам превратить свой рабочий процесс в изящный танец или фортепианную партию.

Фишкой колдовского редактора является то, что вы общаетесь с ним не через аналоговое управление (двигаем мышкой, вводим текст), а через команды и макросы. Зачем заморачиваться и пользоваться текстовым редактором через код?

Потому что это чертовски быстро!

Статья о том, как настроить vim в одном месте, а все файлы, которые находятся на других серверах, подгружать и работать локально. Понятно, что можно поставить vim на каждый удаленный сервер, настроить и работать по ssh, но не всегда есть такая возможность, хотя бы потому, что все быстро устаревает и чтобы использовать супер-современный vim со всеми плагинами и наворотами порой надо заменить OS на удалённом хосте.

Я здесь собрал кое-какие способы (не все), с помощью которых можно редактировать файлы, находящиеся на удаленных машинах, при этом используя свой локально настроенный и причесанный vim со всеми плюшками.

Вашему вниманию конфигурационный файл с плагинами для комфортной разработки под Ruby on Rails и не только.

Более года собирался данный конфигурационный файл, удалялись или устанавливались разные плагины и проходили обкатку. в результате теперь комфортно работать в "самом" быстром редакторе.

Привет, сегодня будет писать конфигурацию для терминального редактора Neovim на чистом Lua. Мы не будем использовать VimScript от слова совсем. Я расскажу в чем плюсы создания таких конфигураций, как соблюдать KISS (Keep It Stupid Simple) все время дополняя такие конфигурации, а также расскажу про полезные плагины для веб-разработки и не только.

В процессе знакомства с Neovim было прочитано много статей, конфигураций на Github, было просмотрено огромное количество роликов на Youtube на тему настройки, но в большинстве случаев приходилось донастраивать все под себя. В этой статье я расскажу как я настроил Neovim для разработки на Go, используя только Lua плагины и init.lua.

В этой статье речь пойдёт про некоторые его преимущества, которые, на мой взгляд, наиболее важны для конечного пользователя.

Статья рассказывает о том, как я с нуля переписывал свой nvim-конфиг (init.vim) в конфиг с поддержкой lua (init.lua).

Несколько дней назад попалась мне одна статья про то, что Vim достаточно хорош как инструмент для разработчика. В комментариях разгорелось очередное противостояние приверженцев vim против остального мира. Мыслей по данному вопросу накопилось достаточно много, поэтому считаю разумным сформулировать их уже в виде статьи. Адепты vim говорят о том что, якобы, освоив vim и полностью настроив его под себя можно получить ощутимую прибавку в скорости разработки. Я же считаю иначе. Лично я в работе использую PhpStorm, поэтому буду сравнивать с vim именно его. Так же оговоримся, что рассматривать инструменты я буду в контексте, А для наглядности рассмотрим как одни и те же задачи будут решаться в IDE и в Vim. Рабочие инструменты берем в состоянии "из коробки". Предполагаем что на компьютере уже установлен vim или IDE в коробочном варианте.

Я немного расскажу, как использую vim в работе full stack программиста, со своей колокольни, но для начала отвечу на некоторые вопросы, которые задают мне, когда узнают, что я использую vim при разработке проектов:

Зачем?

Хороший вопрос. Стоит для себя лично на него ответить. Зачем валандаться с vim, изучать кучу комбинаций клавиш и плагинов? Какой смысл, если есть vscode или pycharm или phpstorm? Жизнь коротка, стоит ли ее тратить на все это? Чтобы впечатлить кого-то, как на картинке в начале статьи? Да кого этим удивишь?