Про Vim " Встроенное
Monticello and the Thomas Jefferson Foundation® Adjustable Magnifier
Перед тем как перейти к использованию LSP и более навороченным плагинам предлагаю проникнуться более продвинутыми встроенными функциями Vim дабы освоить те приемы работы, прежде всего с исходным кодом, которые будут доступны вам с нуля на практически любом дистрибутиве в любом удаленном терминале.
Удаленка
А перед этим хотелось бы немного обосновать почему я так ревностно отношусь к использованию неспециализированных решений. Во-первых — это связано с работой. С какой именно? С такой, что приходится в целях безопасности большую часть времени сидеть в закрытых сетях за сетевыми экранами. И с такой, что я не могу просто так взять и полностью продублировать рабочее окружение у себя, скажем, дома. Мне нужна возможность развернуться в каких-то тестовых контурах, которые задействуют старые добрые виртуальные машины без всяких кластеров и докеров. Более того, нужно время от времени взаимодействовать с коллегами на более интимной основе, чем комментирование кода через систему контроля версий. То есть просто взять, подсесть и ручками что-то где-то показать. Да, и нынче, к сожалению или к счастью, пока существуют и такие сценарии взаимодействия.
Во-вторых — привязка к какому-то «любимому» высоко персонализированному софту в конце-концов приводит к нездоровому привыканию и как следствие к «ломке» при вынужденном отказе. А это рано или поздно случается, даже судя по моему небольшому опыту, просто в следствии прогресса, либо в результате необходимости развиваться самому как специалисту. Да, наверное, можно всю сознательную жизнь прожить на какой-то одной платформе и экосистеме. Ну, например, программируя какие-то инженерные или математические приложения на плюсах, или клепая пользовательские формы под винды на каком-нибудь, прости хосподи, дельфи. И даже такие задачи эволюционируют, и когда-то прогрессивный и всеми любимый инструмент может перестать поддерживаться и превратиться со временем в тыкву.
С другой стороны, я преклоняюсь перед программистами и другим технарями, которым удалось на протяжении десятилетий сохранить простые и консервативные методы работы с текстом несмотря на повальное увлечение специализированными визуальными средствами и графическими интерфейсами. Благодаря которым никуда не делись в свое время консольные программы, нынче переживающие ренессанс и потихоньку возвращающие себе былые позиции. Ведь суть программирования, а точнее набор исходного кода и составление документации к нему — это манипуляция тем или иным образом над текстом. Даже диаграммы и графические формы внутри — ни что иное как специальным образом оформленный текст.
Но это меня повело в сторону. Опыт удаленной работы за последние два или три года показал, что ни RDP ни VNC, ни какие-то другие средства удаленного присутствия всё еще не так хорошо подходят для работы программиста. Когда ты львиную долю времени проводишь в работе с текстовыми редакторами, никакого смысла таскать при этом с собой еще и лишнюю графическую информацию по каналам связи нет. Даже при хорошем и стабильном подключении время реакции удаленной машины начинает сперва быть заметной, а потом и вовсе раздражать. Что уж тут говорить о мобильной связи. Всё время приходится куда-то подключаться заново. Надо ли говорить, что терминальные сервера Windows хороши только в первые пару недель работы с ними и то сеансами не более 15 минут. Скоро, когда терминальным сервером пользуются более чем двое-трое, он деградирует и завтра, вместо запущенных и расположенных на своих местах окошек вы увидите запуск нового сеанса. Что очень быстро начинает раздражать, а вскоре делает нормальную работу в современном смысле невозможной.
В-третьих, операционные системы, даже из пингвиньего семейства, иногда ломаются. Страшно сказать, но ломаются иногда и железяки, в том числе и жесткие диски. И, время от времени, злой админ, или вы сами, сдаетесь и бросаете попытки восстановить систему. Заканчивается это тем, что в один прекрасный день видите вместо привычного красочного приглашения голый баш, на который надо всё накатывать заново. Тут то и возникает вопрос, а надо ли было так увлекаться модификациями? Нужны ли мне для этого конкретного сервера, которым я пользовался то раза два от роду, все мыслимые компиляторы и пакетные менеджеры мира что бы поднять красивый и хайповый NeoVim и отредактировать дюжину файлов? Для меня ответ пока — нет. Когда NeoVim станет неотъемлемой частью большинства популярных дистрибутивов — ради бога — я роняя тапки понесусь заменять алиасы. Ну, а пока, мне кажется, нулевый и каноничный Vim еще более чем актуален.
Орфография
Безграмотное письмо, как ни странно, становится моветоном больше именно в технической среде, нежели чем в каком-то документообороте или даже в публицистике. Кривое именование переменных, косноязычное описание интерфейсов, и другой технической документации признак низкой компетенции и неаккуратности. Жизнь требует от разработчика совершенно новых стандартов красноречия, формализма, точности и знания на неплохом уровне технического английского. Командная разработка не терпит произвола и самодеятельности, в том числе и в обращении с естественными языками. Таким образом, орфография это, если хотите, профессиональный этикет. Понятно, ни кто не будет наказывать рублем за опечатки и грамматику, но, согласимся, то в каком состоянии мы получаем легаси код, даже относительно свежий, часто вызывает если не недоумение, то снисходительную улыбку.
Проверка правописания в Vim как и многое другое встроенная, хотя и по умолчанию выключенна. Для русскоязычных пользователей полезно сразу подгрузить словарь русского языка.
:set spell spelllang=en_us,ru
Имеет смысл ввести эту команду непосредственно в редакторе и потом продублировать в конфигурации .vimrc так как в интерактивном режиме Vim предложит самостоятельно скачать словари и создать необходимые директории и файлы.
Включенная проверка орфографии помимо подсвечивания позволяет тут же перемещаться по опечаткам — [s, ]s пополнять словарь — zg, а также выводить список похожих слов из словаря — z= в нормальном режиме. В режиме вставки же, появляется новый функционал для автоматического дополнения.
Автодополнение
Vim имеет довольно широкий функционал автоматического дополнения (автодополнения) без использования каких либо расширений. «Из коробки» доступны словари формируемые из текущего буфера, регистров, тегов, файлов и всего что можно. В том числе из орфографического словаря. Посмотреть какие из словарей доступны в данный момент можно командой:
:set complete?
Где каждая буковка отвечает за свой вариант источника слов. По умолчанию орфографический словарь, за который отвечает буква k отключен, и его нужно добавлять самостоятельно. Сделать это несложно, но есть один нюанс. Там, где требуется автоматическое дополнение по умолчанию — например, при наборе исходного кода — добавлять огромный орфографический словарь смысла мало. То есть, неплохо было бы сделать так, что бы орфографический словарь подключался только там где он действительно нужен — при наборе текста на естественном языке.
И тут полезным оказывается еще один встроенный плагин — ftplugin, который может различать файлы по имени или по содержимому, вызывая только специфические команды из директории ftplugin/.
Поэтому команду подключения орфографического словаря я бы добавил для конкретного типа, либо воспользовавшись автокомандой следующего содержания:
:au BufNewFile,BufRead *.txt,*.md set complete+=k
Включение словаря в автодополнение делает возможным вызов списка подсказок по горячим клавишам
Помимо орфографии Vim предоставляет массу других вариантов автоматического дополнения по сочетаниям
Опять же, Vim что-то достаточно хорошо умеет и сам. Используя всё тот же ftplugin Vim подключает специфическую для типа файла функцию автодополнения. Для файлов markdown, например, автоматически подключается дополнение HTML тегов. Текущую функцию можно посмотреть командой:
:echo &omnifunc
Всё что дальше подключается посредством LSP серверов по сути переопределяет эту самую функцию и навешивает на неё какую-то комбинацию, привычную для графических редакторов, или включает по умолчанию для любого набора текста. Можно было бы самостоятельно прописать комбинацию типа TAB, но я так делать не буду, потому что, возвращаясь к тираде об удаленке, всё же лучше не отходить далеко от дефолтов.
Netrw vs NerdTree
К дефолтам современного Vim так же относится плагин netrw. Это довольно мощное дополнение, которое фактически является самостоятельной подпрограммой — эдаким файловым менеджером на минималках. Вызывается оно либо специальными командами: Explore, Lexplore и Rexplore, либо просто при попытке отредактировать директорию — :e .
Все прелести и трудности использования этого плагина я описывать не буду, так как сам им не особенно пользуюсь. Скажу лишь то, что, опять же, на безрыбье и он достаточно функционален и позволяет решить 90% задач связанных с файлами аналогичных задачам решаемым в диалогах графических редакторов. Отсортировать, переименовать, создать директорию и даже полазить по сети.
Как разработчику, и человеку избалованному более функциональными менеджерами, мне всё-таки больше понравился сторонний плагин — NerdTree. Этот не тащит за собой зависимостей и по идее должен работать без сторонних библиотек и всяческих систем сборки. Зато он может далее интегрироваться с другими плагинами и украшательствами — как минимум с гитом и специальными консольными шрифтами. Так что это ещё один «джентльменский» плагин, без которого жить в принципе можно, но не очень весело. Особенно разработчику.
" NerdTree
Plug 'preservim/nerdtree'
" NerdTree git support
Plug 'Xuyuanp/nerdtree-git-plugin'
" VimDevIcons for NerdTree and Airline
Plug 'ryanoasis/vim-devicons'
Напомню — все конфигурации описываемые в статьях я всё-таки положил в отдельный репозиторий, так что бы не потерять мысль самому и не ввести в заблуждение читателя. Предыдущие строки выполнять не нужно — они сразу идут в файл ./vim/plugins.vim.
Можно сделать клавиши управления NerdTree похожими на Netrw.
Во всяком случае NerdTree удобнее открывать и закрывать переключателем — открывается древо узким окном слева, там где обычно ожидаешь древо проекта.
" nerd tree toggle
nmap e :NERDTreeToggle
Тем же сочетанием дерево закрывается, что поначалу не сбивает с толку пользователя еще не привыкшего манипулировать окнами.
Окна, буферы, вкладки
Окна вообще говоря сбивают с толку и чуть более опытного пользователя. Окнами в понимании (псевдо)графических интерфейсов окна Vim называть, наверное, не очень корректно. Это скорее такой «viewport» что-ли. Который отображает «буфер». Буферы — это еще одна специфичная для консольных редакторов сущность. Это вроде как и не совсем файл, но, с другой стороны, им конечно же является. Скажем так — это файл, который «загружен» в данный момент в Vim. Слово «загружен» тут тоже в кавычках, так как Vim вовсе не обязательно держит весь файл в памяти в отличии от большинства редакторов которые мы привыкли видеть в графических средах. В чем, кстати, заключается его порой удивительная «экономичность» и скорость. Vim скорее в каждый момент времени удерживает дескриптор файла и частично содержимое, которое необходимо в данный момент для отображения или еще каких-то одному ему известных вещей.
И эти буферы соответственно можно отображать в каждый момент времени в одном из окон. Таким образом, то что можно воспринимать как отдельный диалог или элемент интерфейса это на самом деле просто ограниченные области, в которые можно подцепить любой открытый ранее файл или, например, то же дерево файлов и даже терминал. Я бы даже сравнил такой подход с такой аналогией, что в каждый момент времени где-то за пределами окна существуют и живут какие-то кусочки текста, а окно это то что мы передвигаем в нужное место, что бы производить какие-нибудь над этим кусочком манипуляции — эдакая лупа на большой простыне.
Если немного пообвыкнуть с терминологией и концепцией, окна перестают так сильно ввергать в растерянность при случайном их открытии. Более того, со временем начинает нравиться, что всё что является окном в принципе управляется одинаково: те же движения, выделение, редактирование, вставка и всё прочее. И даже то что любое из окон можно «подвинуть» на любой другой буфер, в том числе и отображающийся в другом окне.
С этой точки зрения со временем атрофируется привычка всё время пытаться «закрывать» «ненужные» в данный момент файлы, потому что они «забирают» какое-то там место. С другой, появляется проблема переключения на нужный буфер. И, я осмелюсь предположить, что «вкладки» придумали для какой-то такой цели — что бы держать в один момент времени ограниченное количество «активных» буферов в фокусе. Пусть все остальные буферы болтаются где-то там и ждут своего часа, а вот в данный момент меня интересуют три файла: documents/builtins.md, .vimrc и .vim/plugins.vim. При этом у меня может быть загружено еще несколько разных файлов типа помощи, тот же netrw, терминал, да и вообще всё что можно. И что бы быстро переключаться только между этими файлами я создаю три вкладки и бегаю по ним по кругу.
Во всяком случае мне удобно размышлять именно таким образом. Да, и при этом каждая вкладка может иметь свою собственную раскладку окон. Вообще большую часть времени у меня открыто в проекте не более семи-восьми буферов, а чаще два-три, так что переключение даже между ними напрямую не вызывает больших проблем. Я просто мотаю взад-перед буферы, либо пользуюсь тем же fzf для отображения их в виде списка.
Наверное. Если очень привыкнуть к тому что вообще ничего и никогда не надо «закрывать». То, наверное, вкладки имеют более выраженную пользу. Я предпочитаю думать о них как о некоем дополнительном измерении — в глубину что ли. Напишите в комментариях, как вы предпочитаете мыслить об этих сущностях. А я в следующий раз попробую наконец разобрать Conquer of Completion — плагин ради которого, собственно всё и затевалось. Вернее даже не конкретно о самом плагине, а о том как в его можно использовать контексте, ну, скажем, работы с БД.
:quit
