VIM *

Существует три основных способа работы с базами данных. В первую очередь, это конечно же родной графический или веб интерфейс. Который, помимо прочего, разбирается как в устройстве СУБД, так и может на лету подгружать структуру текущей БД. Вряд ли кто-то не согласен с тем, что это наиболее удобный способ составления сложных запросов и процедур на целевом диалекте 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? Жизнь коротка, стоит ли ее тратить на все это? Чтобы впечатлить кого-то, как на картинке в начале статьи? Да кого этим удивишь?

В сообществе фанатов текстового редактора Neovim произошло знаменательное событие — вышла версия 0.5, в которой появилось большое количество нововведений:

• встроенная поддержка языка Lua;
• экспериментальная поддержка treesitter;
• и, наконец, встроенный LSP клиент, позволяющий сделать из простого текстового редактора достойного соперника IDE!

Neovim — это модальный редактор, форк редактора Vim, который ставит своей целью улучшение пользовательского опыта при работе с Vim: «Neovim is built for users who want the good parts of Vim, and more».

Мне нравится Neovim своей гибкостью, благодаря которой его можно превратить в очень мощный инструмент редактирования не только текста, но и кода. Как scala-разработчику мне интересно испытать новый встроенный LSP клиент в применении к любимому языку программирования. В отличие от VSCode и даже Vim + CoC настройка LSP клиента в Neovim несколько более сложная, но при этом крайне гибкая. Данная статья — краткое руководство по настройке Neovim для работы со Scala и краткий обзор возможностей, которые дает связка Neovim + Metals.

Долгожданный релиз NeoVim 0.5.0 наконец-то вышел 2 июля 2021 года. Это заняло больше времени, чем кто-либо ожидал, но это того стоило. Более 4000 коммитов, это так много, что сломало некоторые инструменты выпуска. Поэтому эти заметки не смогут затронуть каждое из многочисленных изменений, которые были внесены в ходе разработки, и будут сосредоточены только на наиболее заметных для пользователя улучшениях, самыми крупными из которых являются:

Lua как превосходный язык сценариев и конфигурации.

Протокол языкового сервера (Language server protocol) (LSP).

Treesitter (ранний доступ).