Vim головного мозга

todo

 _______________________________________________________
| terminal - zsh                               [#][-][x]|
|"""""""""""""""""""""""""""""""""""""""""""""""""""""|"|
|~/Repos/blogsite:$ git pull                          |"|
|                                                     | |
|Enter passphrase for key ~/.ssh/id_ed25519:          | |
|Already up to date.                                  | |
|                                                     | |
|~/Repos/blogsite:$ nvim                              | |
|                                                     | |
|                                                     | |
|                                                     | |
|                                                     | |
|                                                     | |
|                                                     |_|
|_____________________________________________________|L|

Вам знакомо ощущение, когда у вас есть инструмент (допустим молоток), которым вы регулярно пользуетесь, но постоянно что-то в нём не устраивает? То ручка у молотка неудобная, то в плечо слишком сильно отдаёт, то неудобно забивать гвозди… Вы начинаете размышлять и анализировать, что не так. Пытаетесь понять разные способы использования, что-то “подпилить”, или же пробуете другой молоток.

Вот меня часто такие ощущения посещают касательно разных инструментов. Пробовать разные связки инструментов: пропиетарные или open-source, набор микро-утилит или “всё-в-одном” комбайны… А поскольку мои работа и хобби связаны с программированием, то главным инструментом у меня является текстовый редактор.

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

А с чего начинали?

Я постарался вспомнить всё то, чем приходилось пользоваться для написания кода в частности и разного рода текстовых заметок (пожалуй за исключением очень особых случаев, типа стандартного Блокнота Windows и каких-нибудь PascalABC да прочих Wolfram Matematica и матлабов) и постарался их расставить в хронологическом порядке их пользования.

Итак, встречайте:

1. Visual Studio (2010 - 2018)

Базированая IDE от конторы (на тот момент) Балмера, с которого я и начал писать. Узнал я о ней из своей первой книги по программированию “C++ Demystified” за авторством Jeff Kent, где предлагалось использовать версии 2005 или 2008 года. С VS2008, в общем-то, я и начал свой путь. И поскольку я тогда только начинал свой путь, то для меня самым важным было то, что “среда может за меня преобразовать мой код в реально работающую программу”, ибо представления, как иначе я могу это делать, кроме как попросить умную среду разработки сделать это за меня, у меня не было.

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

  1. Visual C++ Express 2008
  2. Visual Studio Express 2012
  3. Visual Studio Community 2015
  4. Visual Studio Community 2017

Мажор 2017 стал последней моей студией, поскольку с годами я реже в неё заходил, отдавая предпочтение другим инструментам, и вот почему.

Студия огромная. Я думаю большинство интересующихся знает, сколько она требует ресурсов от компьютера. Даже на этапе установки, инсталлер тебя засыпывает разного рода, типа:

  • “а не хотите ли поставить .NET рантайм времён царя гороха?”
  • “или может быть MSVC C++ 200x года для архитектуры aarchFooBar?”
  • “а мы ещё вам и веб-разработку предложить можем, гыы”
  • etc.

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

Кроме того, студия обязывала пользователя сидеть на оси от мелкомягких, ибо никаких сборок ни под Жму/Линупс ни под Мак нет.

Всё это стабильно напоминало о себе, подталкивая к тому, чтобы

  • во-первых: запускать её как можно реже и только если очень надо
  • во-вторых: задуматься об альтернативных редакторах

Notepad++ (2011 - 2017)

Блокнот плюс плюс стал мной использоваться как замена стандартному блокноту. В нём было всё, что так мне не хватало стандартному блокноту от мелкомягких, а именно:

  • подсветка синтаксиса для разных синтаксисов
  • вкладки
  • нескучные обои темы

Чаще всего я его использовал для правки конфигов и скриптов, но это никогда не было основным редактором, потому что интерфейс выглядит как внебрачный ребёнок IBM и GNU и работать в таком – удовольствие на любителя. Кроме того, несмотря на то, что он поддерживал систему плагинов, она всегда казалась очень неудобной, что тоже заставляло меня “желать лучшего”.

Dev C++ (2015 - 2018)

С 2015 я начал обучение в университете и соответственно я стал часто программировать классические computer science вещи на C и C++, которые мне там задавали. А вместе с этим я стал подрабатывать у родителей. И иногда на подработке у меня появлялось свободное время, в которое я хотел иметь возможность писать эти университетские задачи.

На рабочий компьютер совсем не хотелось ставить тяжёлую студию, поэтому я искал альтернативы. Про то, как можно пользоваться напрямую gcc я ещё не знал, поэтому я искал IDE, которая проделает процесс сборки за меня, не посвящая в подробности, но при этом была бы легче, чем MSVS. И я нашёл такую: Dev C++.

Интерфейс был невероятно минималистичным по меркам IDE и больше походил на тот же Notepad++, но с урезанным функционалом, но при этом с выведенными кнопками под сборку/дебаг. И меня это более чем устраивало, потому что все приложения, что я тогда писал – все были CLI-based, а значит возможности типа Window Designer и прочее связанное с WinForms или другим API мне было не нужно.

Она помогала мне решать эти задачи, но со временем задачи становились сложнее и со временем они вышли за рамки CLI, а значит мне нужно было двигаться дальше…

XCode (2015 - 2017)

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

  1. Бывали моменты, когда отлаженные дома исходники переставали собираться на университетском ПК и приходилось в срочном порядке разбираться, что пошло не так. По старой доброй традиции тулчейнов C и C++, ошибок было невероятно много и подавляющее большинство было максимально неинформативно, что приводило к деморализации.
  2. Иногда одной пары было просто недостаточно, чтобы сдать работу ""от и до”, и показ работ переносился из компьютерных классов в другие места, где машин уже не было.

Посему большинство студентов чаще стало предпочитать приносить собственный ноутбук, на котором можно было заранее удостовериться, что билд проходит нормально и, в случае чего, можно показать работу вне времени пары. А поскольку у меня дома не было ноутбуков с живой батареей, кроме отцовскго MacBook Air 2013, то пришлось брать его. И опять же, пользоваться gcc я не мог, про JetBrains я тогда ещё не знал, да и вообще “интернетные знатоки” твердили:

хочешь кодить на маке – XCode тебе в руки

И поэтому всё так произошло…

О Один всемогущий, какое отторжение она вызывала у меня. Абсоллютно ублюдский фирменный Apple-fashioned интерфейс, который по идее должен был упростить создание проектов, но по факту только мешал… постоянные несовместимости… абсолютно гадские ситуации, когда ты подготовил исходники на windows окружении (без использования Windows-specific вещей, только libc_), переносишь это дело в XCode… и радуешься абсолютно новым, неизведанным ошибкам, которые нехотя, но пытаешься починить.

Не стоит и говорить, что как только появилась возможность не прикасаться к этому отродью, я незамедлительно воспользовался ею.

VSCode (2018)

В 2018 я узнал о таком явлении, как “текстовый редактор, ориентированный на написание кода” и Visual Studio Code был одним из самых зафорсенных. В том году я уже почти не программировал на C/С++, иногда брал в руки C#, если нужен был GUI, или же брал Python, если графика не требовалась. И как раз для написания скриптов на Python я думал и попробовать VSC, тем более, что Мелкософт сделал его кроссплатформенным, что давало +10 очков к нему.

Увы, я не помню уже конкретно, что меня оттолкнуло в нём тогда, но долго я не смог на нём усидется – что-то было в нём для меня неудобное, тем более мне показался более удобным другой редактор…

Atom (2018 - 2020)

На Atom я просидел определённое количество времени и впечатления были положительные. Меня подкупала его минималистичность и неориентированность на работу с конкретным стеком технологий. Конечно конкуренты может и могли предложить более функциональные вещи, но у меня не было тогда запроса на умный intellisense или интеграцию с someframework. Да и я ещё не был избалован разного рода программерскими помогалками и сходить в документаци того же Python было ещё не лень.

Под такое описание конечно подходил и Notepad++, но ощущение нафталина не покидало при его использовании, поэтому Atom стал для меня одним из основных средств разработки на какое-то время.

Увы проект не выдержал конкуренции с VSCode и загнулся где-то в 20-х годах. Good night, sweet prince!

JetBrains (2018 - present)

Параллельно с Atom я всё же пользовался и продуктами от JetBrains, потому что в некоторых проектах определённая навороченность требовалась. Были проекты и на Django, и при работе с Java стеком - PyCharm и IntelliJ были крайне удобными. В общем-то они удобны настолько, что я стал очень на них полагаться. Я стал принебрегать такими вещами, как чтение документации. А если раньше я спокойно мог накидать код без умного автокомплита, который мог предлагать варианты исходя из текущего контекста, то теперь уже без этого стало действительно некомфортно. Начинаешь замечать, что PyCharm и предложит в автокомплите методы и свойства объекта, которые по идее не инференсятся из типа данных, но которые на самом деле доступны (привет Django), и сможет автоматически нагенерировать utility-код (привет Java), и вообще это же так удобно, когда ты можешь позапускать один конкретный тест, который отлаживаешь, не вводя в шелл длинную exec строку.

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

И всё-таки очень часто не хочется инстанцировать JVM вместе с запуском этого монстра, а значит ниша легковесного редактора была ещё актуальна. И мы наконец подходим к нашему гвоздю программы…

Сегодня выступает легендарный Vim

Где-то под конец 2019 меня посетила такая мысль: крутые дяди и тёти настолько крутые, что клали прибор на модные fancy штуки, а пользуются такими технологиями древних, как Emacs и Vim. Меня эта мысль всегда интриговала, мол “что же такого привлекательного они нашли в них”. И я решил попробовать…

Выбор пал на Vim почти сразу по одной причине: он был в 99% доступен на любой Linux машине (а мне на тот момент частенько приходилось что-то накодить прямо на удалённой тачке через ssh), чего я не мог с уверенностью сказать про Emacs. Кроме того, я был очень наслышан про монструозность хоткеев в Emacs, при которых твой левый мизинец, после двух месяцев использования, принимал такую форму, чтобы можно было спокойно и постоянно прожимать Lctr. Про Vim раскладку и её “интуитивность” я конечно тоже был наслышан, но мне это показалось более щадящим шилом в одном месте.

Вооружившись vimtutor-ом и статьями с опытом от других, чтобы не остаться один на один с крутой кривой обучения, я начал путь:

База

Минута молчания в честь тех, кто выходил из вима…

Навигация

Начал я естественно с того, что нужно было освоиться с базовой навигацией и командами. Конечно поначалу курсор я двигал стрелочками, символ за символом, что было, мягко говоря, НЕБЫСТРО. Да и стрелочки — не труЪ, поэтому некоторое время я явно себя ловил каждый раз, когда рука тянулась к тому блоку и говорил себе

use the force hjkl…

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

Воистину дела стали лучше, когда я узнал про { и } — прыжок курсора к следующему и предыдущему началу параграфу (пустая строка). О да, это было для меня открытием, потому что это стало для меня основным способом перемещаться между методами/классами, так как они как раз часто и были разделены пустыми строками.

Также абсолютной необходимостью был поиск подстроки в открытом файле: хоткей / для начала поиска, n и N для следующего и предыдущего нахождения строки. Работает хорошо и исправно — можно искать и по регэкспам, что порой крайне удобно. И это тоже ускоряет навигацию по файлу.

Режимы

Vim также известен тем, что это модальный редактор. Это значит, что у него есть несколько режимов работы:

  • NORMAL: клавиатура используется для навигации по файлу или использования команд; текст не редактируем (в привычном понимании). Все хоткеи, которые я упоминал выше, вводятся именно в этом режиме.
  • INSERT: режим вставки символов под курсором (то, что делают классические блокноты).
  • REPLACE: примерно то же самое, только вместо добавления символов, они заменяют те, что были под курсором. Похожий эффект можно наблюдать, если нажать в любом другом редакторе клавишу Insert и попробовать напечатать что-то посреди другого текста.
  • VISUAL: режим выделения символов в строках. При переходе в режим, выделение начинается там, где стоял курсор, и продолжается дальше под курсором, пока не будет введена другая команда.
  • VISUAL BLOCK: всё то же самое, что и в VISUAL режиме, кроме того, что можно выделять выборочно символы из нескольких строк (например “квадрат” — символы с 4 по 8 на строках 4-8).

По умолчанию стоит NORMAL режим, в любом другом режиме Esc возвращает обратно в NORMAL. И концептуально у меня не возникло проблем с такой идеей и я быстро приноровился к этому, за исключением REPLACE режима — уж больно для меня оно ощущается как “не нужно”.

Копирование-вставка-удаление

Для удаления символов я узнал, что нужно использовать вариации команд d (delete). И я этого поначалу не понял зачем — я же могу по классике стереть все те символы через Backspace. А потом я понял и проникся, потому что так удалять символы очень медленно. А через d... ведь можно всего в пару нажатий:

  • удалить одно слово: daw
  • удалить всю строку: dd
  • удалить целый параграф: dap
  • удалить всё, что внутри парных символов (например "" или ()): di" и di(

Последнее особенно меня впечатлило, потому что менять контент заковыченных строк — частая необходимость, и возможность снести её в три нажатия клавиши подкупает, в сравнении с долгим задерживанием Backspace или елозением мышкой. Кроме того d* работает как cut — удалённые символы помещаются в буфер обмена и можно позже вставить удалённые символы при помощи p (paste).

Для простого копирования команды имеют похожую семантику, за исключением первого символа: y (yank):

  • скопировать одно слово: yaw
  • скопировать всю строку: yy
  • скопировать целый параграф: yap
  • скопировать всё, что внутри парных символов: yi", yi(, …

Впрочем с копипейстом были небольшие проблемы поначалу. Дело в том, что Vim из коробки использует свой собственный буфер обмена. При вставке символов, он будет использовать только свой буфер (куда попадает только то, что было скопировано внутри Vim), и игнорирует то, что было скопировано в другом приложении. И поэтому я какое-то время не мог вставлять куски кода, найденные на каком-нибудь Stack Overflow. Намного позже я узнал, что для вставки из system clipboard можно добавлять + к команде — тогда Vim будет ссылаться именно на стандартный буфер. А пока я этого не знал, я использовал ПКМ > Paste, что меня невероятно калило, но что ж поделать.

На самом деле ещё раньше я узнал, как сделать так, чтобы Vim по умолчанию использовал системный буфер при y*, но я какое-то время не включал его, потому что мне стало удобно использовать два разных буфера: когда в стандартном было всё в перемешку — от кусков кода до рофлов с рабочего чатика; буфер Vim-а был всегда заполнен только релевантным для файла содержимым. Но по итогу я всё же пришёл к тому, чтобы использовать везде только системный буфер.

Макросы

А ещё я узнал про то, что в виме можно создавать макросы — последовательности команд редактора. При нажатии в NORMAL режиме qq активируется запись макроса. Ты записываешь последовательность клавиш и команд и заканчиваешь макрос через q. Макрос будет записан и его можно применить по нажатию Q.

Поначалу я посчитал это каким-то ненужным задротством, но на самом деле это оказалось невероятно полезно. Например если есть файл, в котором есть строки, содержащие “/* TODO:…*/” и вы хотите удалить их все в текущем файле. Руками пришлось потратить некоторое время, чтобы пройтись по всему файлу, найти такие строки и руками их удалить. А вот, как это можно решить при помощи макроса:

  1. Ищем через / регулярку \/\* TODO:.*\*\/
  2. Записываем макрос:
    • gn - перейти к следующей найденой строке и выделить её
    • d - удалить выделенное
  3. Зажимаем Q
  4. Макрос будет удалять нужные строки пока их не останется в открытом файле

На самом деле для массового удаления/замены строк чаще используется команда типа :%s/string-to-replace/replacement/gc, но во-первых я часто забываю как пользоваться такой командой, а во-вторых я хотел показать, что макросы - универсальный инструмент, который может быть полезным и при этом не требует знания определённой части вима; если ты знаешь только как передвигаться по файлу посимвольно и удалять строку целиком, то этого уже достаточно, чтобы получать профит от использования макросов.

Боль моя русская дырка задница

Есть у вима одна неприятная особенность, про которую знают только те, у кого на компьютере стоит не только EN-раскладка клавиатуры. Так уж вышло, что Vim при обработке нажатых клавиш, ориентируется на их ASCII-код. Что это значит? Ну например, когда ты хочешь перейти на строку ниже через нажатие j, vim получает его код (106) и это для него является триггером, чтобы переместить курсор на строку ниже. Уже догадались какая проблема здесь зарыта? =)

Это значит, что если ты сидишь на русской раскладке, то нажатие на j ничего не сделает, потому что вим получит код для символа о (222), а на такой код у вима нет определения команд. Как неожиданно и приятно!

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

Плагинчики, настроечки, vimscript

С кором плюс-минус освоился, но всё же в ванильном виде, Vim едва ли лучше других редакторов. А всё потому что вся соль в кастомизации. И тут есть где разгуляться, потому что это неважно, хочешь ли ты иметь компактный инструмент для правки кода, в котором будет по минимуму плагинов, самых-самых полезных… или же ты хочешь построить свою IDE, с 9999 интеграций с инструментами и сервисами на все случаи жизни — плагин система Vim-а позволит тебе всё это сделать.

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

… и его популярный внук Neovim

TODO

Сборки ZverVim 9999-in-1

TODO

“Бумер спок, никому уже не нужны твои советские молотки!”

TODO

Теги: software