Мои предыдущие посты об использовании Vim (1, 2) читатели приняли хорошо, и пришло время обновления. В Vim 8 появилось много очень нужной функциональности, а новые сайты сообществ вроде VimAwesome облегчили поиск и выбор плагинов. В последнее время я много работаю с Vim и организовал рабочий процесс исходя из максимальной эффективности, вот снимок моей текущей работы.

Вкратце:

• FZF и FZF.vim — для поиска файлов.
• ack.vim и ag — для поиска файлов.
• Vim + tmux — ключ к победе.
• Благодаря асинхронности ALE — это новый Syntastic.
• …И многое другое. Об этом ниже.

Недавняя Vim-сессия

Как обычно, все желающие могут скачать мои dot-файлы и vimrc. Также я приготовил отдельный установочный скрипт для обновления и установки Vim-плагинов.

FZF

TextMate и Sublime Text показали нам, что самый быстрый способ поиска файлов — нечёткий поиск (fuzzy finding), когда вводишь части имени файла, пути, тега или чего-то ещё. Иногда срабатывает, даже если символы не расположены рядом друг с другом или когда ошибаешься в написании. Нечёткий поиск настолько полезен, что в современных текстовых редакторах превратился в стандартную функцию.

Годами властелином нечёткого поиска был Ctrl-P, однако новый инструмент FZF оказался быстрее и неприхотливее при поиске одного файла или тега среди тысяч других. Ctrl-P нормально работал в моей кодовой базе из 30 000 файлов на MacBook Pro 2013 года, но начал тормозить при поиске по огромному файлу с тегами, причём настолько, что им просто невозможно пользоваться. А скорость работы FZF вообще не меняется — он одинаково быстро ищет и по файлам, и по тегам.

Начать работать с FZF просто. Достаточно следовать инструкциям по установке (brew install FZF на macOS с помощью Homebrew) и установить дополнительный плагин FZF.vim, чтобы получить адски быструю функциональность.

FZF сопровождается базовым Vim-плагином, но его функциональность минимальна, так что FZF.vim предназначен для предоставления всех нужных вам возможностей. Самые полезные команды — :Buffers, :Files и :Tags, я привязал их к ;, ,t и ,r соответственно:

nmap ; :Buffers<CR>
nmap <Leader>t :Files<CR>
nmap <Leader>r :Tags<CR>

Для меня важна привязка ;, потому что я живу буферами. Я практически не использую вкладки — об этом поговорим ниже, — поэтому мне важно, что я могу с минимальными усилиями переключаться на то, о чём размышляю.

Удостоверьтесь, что FZF применяет ag, замену grep/ack под названием Silver Searcher. ag будет уважительно относиться к вашим файлам .gitignore и .agignore, так что больше нет нужды хранить огромную строку wildignore в своём vimrc.

FZF также может работать в оболочке, он идёт с биндингами для Zsh, Bash и Fish. В Zsh я могу нажать Ctrl-t для мгновенного запуска нечёткого поиска любого файла в текущей директории. И поскольку я сконфигурировал FZF для использования ag, он игнорирует всё, что исключено в .gitignore. Это замечательно.

Вот кусок кода из моего .zshrc. Когда FZF вызывается из Vim, то также используются переменные среды FZF:

# FZF via Homebrew
if [ -e /usr/local/opt/FZF/shell/completion.zsh ]; then
  source /usr/local/opt/FZF/shell/key-bindings.zsh
  source /usr/local/opt/FZF/shell/completion.zsh
fi

# FZF via local installation
if [ -e ~/.FZF ]; then
  _append_to_path ~/.FZF/bin
  source ~/.FZF/shell/key-bindings.zsh
  source ~/.FZF/shell/completion.zsh
fi

# FZF + ag configuration
if _has FZF && _has ag; then
  export FZF_DEFAULT_COMMAND='ag --nocolor -g ""'
  export FZF_CTRL_T_COMMAND="$FZF_DEFAULT_COMMAND"
  export FZF_ALT_C_COMMAND="$FZF_DEFAULT_COMMAND"
  export FZF_DEFAULT_OPTS='
  --color fg:242,bg:236,hl:65,fg+:15,bg+:239,hl+:108
  --color info:108,prompt:109,spinner:108,pointer:168,marker:168
  '
fi

Я собирался написать об одном большом недостатке FZF: это внешняя команда, не работающая с MacVim. Но теперь всё изменилось! Поддержку добавили недавно с помощью новых нативных терминалов в Vim 8. Работает хорошо, но гораздо медленнее, чем терминал в большой кодовой базе (~1 млн файлов).

Помимо нечёткого поиска

Хотя FZF, Ctrl-P и другие редакторы поддерживают нечёткий поиск по путям и именам файлов, я надеюсь, что кто-нибудь создаст для Vim поиск по первым символам. Например, в IntelliJ, если вы хотите открыть класс FooFactoryGeneratorBean, то жмёте Cmd-o и пишете FFGBEnter (первые символы каждой части имени класса). Это очень удобно для поиска тегов, потому что имена классов часто пишутся в Camel-регистре вне зависимости от языка программирования. Можно, например, обрабатывать символы до знака подчёркивания как первые символы, так что fbbq будет соответствовать файлу вроде foo_bar_baz_quux.js.

Поиск и окно QuickFix

Ag — это новый ack, который был новым grep. На первый взгляд, лучший способ использовать ag из Vim — ack.vim, но это заблуждение, потому что ag.vim устарел, но ack.vim поддерживает и ack, и ag.

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

Обратите внимание, что :Ack по умолчанию переходит в списке QuickFix к первому результату. Если вам это не нравится, используйте :Ack!, или поменяйте местами функциональность двух команд в конкретном документе.

(Вас может смутить, что FZF.vim добавляет команду :Ag, интерактивно использующую FZF для поиска с помощью ag. Я для пробы привязал её к ,a. Не заметил особого толка, но типа круто.)

Когда результаты появятся в окне QuickFix, самый простой способ их использовать — переместить курсор и нажать Enter для открытия результата. Также для навигации по списку есть команды :cnext и :cprev, и я пытался найти подходящие кроссплатформенные комбинации клавиш, но не нашёл. Затем я открыл для себя vim-unimpaired, добавляющий полезные биндинги вроде [q и ]q для :cprev и :cnext. На самом деле в vim-unimpaired гораздо больше привязок для пар «вперёд/назад» — навигация по ошибкам компилятора/линтера и включение популярных опций вроде номеров строк, которые, как я считаю, должны быть встроены в Vim.

Использовать окно QuickFix для результатов поиска так удобно, что я написал несколько биндингов для поиска по текущему слову под курсором. Как exhuberant-ctags пытается искать теги в Ruby и CoffeeScript, иногда нужно просто поискать по слову, на которое смотришь:

nmap <M-k>    :Ack! "\b<cword>\b" <CR>
nmap <Esc>k   :Ack! "\b<cword>\b" <CR>
nmap <M-S-k>  :Ggrep! "\b<cword>\b" <CR>
nmap <Esc>K   :Ggrep! "\b<cword>\b" <CR>

Наконец, после поиска и навигации я обычно жму \x (привязано к :cclose) для закрытия окна QuickFix. Вероятно, мне понадобится снова вернуться к файлу, который я смотрел перед началом поиска, так что обычно я повторяю Ctrl-o несколько раз, тем самым перепрыгивая обратно по списку переходов, словно жму кнопку «Назад» в браузере. В другие разы использую; для поднятия списка из буфера и поиска там оригинального файла. Но теперь, когда я об этом задумался, возможно, изменю на O глобальную отметку (global mark) в своём биндинге Meta-k, так что 'O будет всегда возвращать меня туда, откуда я начал.

Терминалы, панели и уплотнение (multiplexing)

Я уже когда-то упоминал, что редко использую gvim/MacVim. Предпочитаю терминал, но есть ряд веских причин, чтобы выбрать отдельное приложение Vim:

1. Оно более отзывчивое, чем Vim внутри tmux внутри терминала.
2. Для открытия txt-файлов под MacOS и Windows лучше использовать приложение по умолчанию, а не TextEdit.
3. В широких окнах редактирования у него не проблем с кликами после 220-й колонки.
4. Если вы пишете длинный пост в блог с большим количеством ошибок и терминал Vim не выделит их подчёркиваниями. Или если вы предпочитаете волнистое подчёркивание.
5. Если вам нужна настоящая цветовая схема Solarized вместо того кощунства, которое получилось при сжатии Solarized до 256 цветов.

Помимо близости к командной строке, другая важная причина использовать Vim в терминале — tmux. Он популярен для удалённой разработки, но удобен и для локальной. Сегодня tmux присутствует в моём повседневном полноэкранном рабочем окружении, а Vim обычно занимает одну из панелей tmux. Это позволяет мне использовать Vim, держа при этом открытыми несколько оболочек — обычно сервер и одну-две панели с утилитами. Иногда я временно раскрываю Vim на весь экран с помощью сочетания клавиш.

Киллер-фича tmux — возможность откуда угодно отправлять нажатия клавиш в панели. Я использую tmux и Vim в качестве IDE: могу редактировать в одной панели, исполнять команды в другой, при этом держа перед глазами лог сервера на случай ошибок. Например, если я работаю с конечной точкой REST, то могу заново протестировать её с помощью curl и просмотреть выходные данные с помощью jq, нажав всего несколько клавиш:

Обычно я вношу изменения в Vim, для сохранения жму :wEnter, затем с помощью <prefix>h перехожу в левую панель (где <prefix> — это префикс-комбинация клавиш tmux, обычно Ctrl-a), затем UpEnter для повтора команды, и наконец <prefix>l для возвращения в Vim. Но гораздо быстрее будет соорудить для этого биндинг в Vim:

nmap \r :!tmux send-keys -t 0:0.1 C-p C-j <CR><CR>

Запускается команда tmux send-keys, которая приказывает отправлять нажатия клавиш сессии, окну и панели 0:0.1, где я до этого запускал curl. Затем туда отправляется Ctrl-p, что аналогично нажатию Up, в результате из истории извлекается последняя команда, а после Enter для исполнения. Я привязал это к \r как run или repeat. Подробнее о send-keys можно почитать здесь и здесь.

Этот подход помогал мне полгода и очень сильно повысил мою производительность. Но нужно сказать, что теперь Vim 8 поддерживает нативные терминалы внутри редактора, и после некоторого использования они мне показались весьма толковыми. До этого разные плагины пытались интегрировать в Vim терминалы с посредственными результатами. Новые нативные терминалы работают быстро, чувствительны к Unicode, поддерживают 256 цветов и используют новую функцию term_sendkeys(), позволяющую по примеру tmux отправлять нажатия клавиш. Это появилось в Vim всего несколько месяцев назад, так что мне ещё нужно поэкспериментировать. Кто знает, возможно, вместо tmux я выберу сплиты MacVim в сочетании с :terminal.

Примечание о терминалах на macOS

Сколько себя помню, вместо стандартного MacOC-терминала Terminal.app я выбирал iTerm2. И недавно заметил, что при наборе в Vim внутри iTerm2 чувствуется медлительность, особенно внутри tmux. Для сравнения я попробовал использовать urxvt внутри XQuartz, и всё работало молниеносно. Что-то добавляло ощутимую задержку, но я не собирался делать urxvt своим основным терминалом на macOS из-за проблем с буфером, с переключением и отсутствием поддержки высоких значений DPI в XQuartz.

Несколько дней спустя я прочитал статью, в которой говорилось о задержке ввода между терминалами на macOS и утверждалось, что Terminal.app теперь значительно быстрее iTerm2. Я попробовал сам и обнаружил, что длительность задержки после нажатия клавиш была где-то между urxvt и iTerm2, так что я полностью перешёл на Terminal.app. Я включил причудливую цветовую схему и был рад найти проект, который конвертировал все темы под Terminal.app.

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

Написание прозы в Vim

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

Прекрасный плагин goyo.vim добавляет в буфер много функций и прячет всё лишнее. Он распознаёт status bar’ы Airline/Powerline/Lightline и тоже их прячет, ну, по большей части. Это плюс несколько других хитростей в настройке я называю режимом прозы:

function! ProseMode()
  call goyo#execute(0, [])
  set spell noci nosi noai nolist noshowmode noshowcmd
  set complete+=s
  set bg=light
  if !has('gui_running')
    let g:solarized_termcolors=256
  endif
  colors solarized
endfunction

command! ProseMode call ProseMode()
nmap \p :ProseMode<CR>

Эту команду я привязал к \p. Она включает Goyo и избавляется от всяких забавных вещей, полезных при написании кода, например отступов при вводе скобок. Также плагин меняет цветовую схему с моей обычной тёмной на светлую версию Solarized. Это важно, поскольку визуально напоминает, что я в «режиме письма» и что нельзя отвлекаться: нужно создавать текст.

Команда также заставляет функцию автозавершения вытаскивать слова из словаря, когда я нажимаю Tab в надежде, что могу писать быстрее. Эта фича всё ещё в разработке, но время от времени бывает полезна.

Линтинг

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

Lightline, Powerline, Airline и строки состояния

Я работал с Powerline несколько последних лет и в конце концов преобразовал его в более легковесный Airline. Но информация и виджеты в строках состояния больше отвлекают, чем приносят пользы. Мне не нужно знать текущую кодировку файла или тип синтаксиса. Кроме того, меня не радуют его шрифты. Я перешёл на Lightline и приложил немного усилий для его минимизации и добавления иконок статуса линтера:

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

Git

Если используете Git, вам будут важны несколько плагинов.

vim-gitgutter показывает маркеры для любых строк, которые были добавлены, удалены или изменены, как это сегодня делают большинство других редакторов. Для изменений я сделал отображение цветной точки (•) вместо символов - и + по умолчанию, так понятнее.

vim-fugitive — самый популярный Git-плагин для Vim, у него масса возможностей. У меня куча алиасов оболочки для Git, поэтому в Vim я редко использую что-то кроме :Gblame и :Gbrowse, но здесь много других приятных вещей, которые ты ожидаешь от встроенных в редактор Git-инструментов (если ваш репозиторий хостится на GitHub, то вам понадобится vim-rhubarb, чтобы заработала :Gbrowse).

:Gbrowse просто чудо — она открывает в браузере текущий файл с опциональным выбором строк, предполагая, что ваш репозиторий зеркалируется на GitHub, GitLab или в другое место. Теперь при использовании для решения проблем и запросов на включение кода стало ещё полезнее отображение в GitHub ссылок на конкретные коммиты и номера строк в виде фрагментов кода. Достаточно с помощью Shift-v выбрать несколько строк, выполнить :Gbrowse, скопировать открывшийся URL и вставить в GitHub комментарий:

Я планировал поговорить о RootIgnore и о том, как он автоматически настраивает wildignore на основе ваших .gitignore. Но это оказалось не лучшей идеей, потому что в командной строке Vim не работает автозавершение путей по нажатию Tab, если путь находится в wildignore. Более того, встроенная функция expand() возвращает null, если путь, который вы просите её расширить, находится в списке игнорируемых. Я не сразу вычислил, что из-за этого мой прописанный в .gitignore и зависящий от хоста файл .vimlocal не будет предоставляться моим зарегистрированным .vimrc.

Буферы, буферы, буферы

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

С буферами легко разобраться: после запуска Vim любой открытый или созданный вами файл превращается в именованный буфер. Вы можете просматривать их с помощью команды :buffers и перемещаться к какому-то из них с помощью :buf <name>, где <name> — любая часть имени файла буфера. Либо с помощью номеров, которые выводятся по команде :buffers.

Если вы запускаете Vim из командной строки с несколькими файлами в виде аргументов, то каждый файл уже будет открыт в буфере. Если вы установили vim-unimpaired, то для простой навигации между буферами помогут биндинги [b и ]b.

Я существенно ускорил этот процесс, забиндив на клавишу ; FZF-команду :Buffers, так что по одному нажатию кнопки получаю список буферов с функцией нечёткого поиска. Например, если я открыл в командной строке три файла vim foo.txt bar.txt quux.txt, то для перехода к quux.txt достаточно набрать ;qEnter. (Да, похоже на использование :buf, но FZF показывает живой предпросмотр, когда у вас открыто много файлов с похожими названиями.)

Иногда я случайно создаю буферы, например, когда пытаюсь открыть файл, ввожу :e и слишком быстро жму Enter. Команду :bd можно использовать для стирания буфера и удаления его из списка, но тогда ещё закроется окно Vim или сплит, в котором открыт этот буфер. Хорошее решение — bufkill.vim, предоставляющий :BD для стирания текущего буфера и сохранения открытым текущего окна. Я часто им пользуюсь, поэтому привязал к Meta-w.

Если нужно переименовать, сделать chmod или удалить файл, то можете перейти в терминал и внести изменение, но тогда буфер Vim перестанет быть синхронизирован и покажет раздражающее предупреждение «File is no longer available». Лучше взять NERDTree и подсвечивать текущий файл с помощью :NERDTreeFind, нажав m для изменения и выбрав действие вроде перемещения или переименования. Я предпочитаю vim-eunuch, добавляющий ряд команд: :Chmod применяет chmod к текущему файлу, :Rename переименовывает файл в его родительской директории, :Move может перемещать файл в другое место, а :Delete удалит файл и буфер. Есть ещё несколько команд, но к этим я прибегаю чаще всего.

Прочие плагины

Мне подсказали плагин vim-polyglot, в котором больше 100 синтаксических плагинов собраны в единый пакет. Он загружает их только по требованию. Все версии свежие, автор выбрал лучшие плагины, чтобы для большинства популярных языков хорошо работали отступы и подсветка.

Комментирование кода — это повседневная задача, так что имеет смысл выбрать плагин, достаточно умный для комментирования строк или блоков кода на разных языках. Вы можете взять :s/^/#, если пишете код, использующий хеши для комментирования строк, но я предпочитаю плагин vim-commentary. Он позволяет с помощью команды gc закомментировать или раскомментировать код на любом языке.

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

Если пишете на Ruby или другом языке с ключевыми словами для завершения блока, то вам много раз приходится повторять end. Плагин endwise вставляет их автоматически. А если вы пишете на HTML или XML, то очень рекомендую closetag.vim, автоматически закрывающий теги после ввода </.

В исходном посте я упоминал о макросах для исправления табуляций и пробелов, чтобы можно было работать с кодовыми базами, использующими разные вариации табуляций и пробелов. Но sleuth.vim может определять эти настройки автоматически, сканируя файлы при открытии. Он работает 90 % времени и делает эти макросы бесполезными.

Мысли о плагинах

Экосистема плагинов процветает благодаря недавним улучшениям в Vim и VimL, например управлению асинхронными процессами и некоторым обязательным типам (indispensable types). Новый сайт с плагинами VimAwesome облегчил поиск популярных плагинов и содержит хорошо структурированные документы и инструкции по установке.

В некоторых отзывах на мои предыдущие статьи критиковалось использование Vim с большим количеством плагинов. Часть таких отзывов можно отнести к понятным подозрениям: любая система, позволяющая добавлять неконтролируемые расширения для изменения любой своей части без ограничений, легко может превратиться в бардак. Посмотрите на WordPress. Или, если застали те времена, вспомните ужасы расширений Mac OS Classic. Невозможность объявить зависимости или отладить взаимодействие между плагинами превратилась в норму.

Но плагины для Vim не так плохи. Отладка взаимодействия между плагинами Х и Y обычно предполагает гугление по фразе «vim X with Y», и мне пришлось делать это лишь один или два раза. Однажды я столкнулся со странностью, для решения которой пришлось использовать двоичный поиск (binary-search) и переименовать один плагин, чтобы он грузился перед другим. Я не хвастаюсь, но пока это единственная проблема во взаимодействии плагинов, с которой я столкнулся.

Отчасти неприятие плагинов — своеобразная пуристская враждебность к отклонению от основного набора функциональности Vim. Но если вы используете Vim, то уже входите в подмножество людей, которым нужно быстрое и эффективное редактирование текста, так что это похоже на группу сумасшедших, спорящих о том, кто из них наиболее эксцентричен. Люди, которые выбрали плагины вроде EasyMotion или vim-sneak, будут утверждать, что работают эффективнее пользователей ванильного Vim. А пользователи ванильного Vim скажут, что они эффективнее тех, кто не выбрал Vim, и т. д.

Также я слышал о практическом сопротивлении использованию плагинов, когда плагину нужна версия Vim с Ruby, или Python, или ещё с чем-то вкомпилированным, а может, плагину нужно самого себя скомпилировать. Vim 7 привнёс в язык много существенных изменений, так что многие плагины написаны на чистом VimL и не нуждаются в дополнительных языковых зависимостях. В сочетании с vim-pathogen, добавляющим в runtime-путь Vim всё содержимое ~/.vim/bundle/, добавить плагины так же просто, как выполнить git clone.

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

Vim не единственный редактор

Есть много других интересных редакторов. Atom и Microsoft Visual Studio Code развились настолько, что вполне практично использовать браузерные нативные приложения. Sublime Text остаётся прекрасным приложением. IntelliJ IDEA теперь имеет бесплатную версию Community Edition. Все они поддерживают режимы наподобие Vim и достойны того, чтобы вы попробовали их в определённых ситуациях.

Программисты-новички часто спрашивают меня, какой редактор выбрать. И я всегда предлагаю начать с Sublime Text. У него знакомый интерфейс, прекрасная экосистема плагинов с актуальной подсветкой синтаксиса, он хорошо работает на macOS, Windows и Linux. Если вы учитесь программировать, то вам не нужно забивать голову странными таинственными комбинациями символов и разными режимами редактирования только для перемещения и изменения текста на экране. Хотя кто-то потом выберет Vim и отметит его скорость и мощь.

Лучший редактор для Java, пожалуй, IntelliJ IDEA. Версия Community Edition бесплатна и имеет все возможности, которые, вероятно, понадобятся современному Java- или Kotlin-разработчику. Здесь хорошая встроенная поддержка Maven-сборки, качественная интеграция с Git, невероятная поддержка рефакторинга, интеллектуальное завершение набираемого текста, классные подсказки параметров функций, умное индексирование, поиск лучше ctags, интерактивный отладчик. Когда я пишу на Ruby, если нужно что-то отладить и вставить больше парочки puts, то я запускаю IntelliJ и работаю с его отладчиком. А если скучаете по Vim, то бесплатный плагин IdeaVIM даст вам привычные биндинги.

Я не пробовал Visual Studio Code, но могу воспользоваться им, когда начну писать на TypeScript, поскольку оба разработаны Microsoft и хорошо работают вместе. Я видел несколько видеороликов и впечатлён его возможностью завершать набираемый текст. Да и вообще читал много положительного о нём. Мой друг утверждает, что Vim-плагин YouCompleteMe очень полезен, если пишете на C или C++, и у него есть поддержка TypeScript.

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

Заключение

Сегодня я сосредоточился на выполнении задач, а не на возне с инструментами. Но Vim всегда был одной из тех вещей, которые стоит немного дорабатывать и исследовать. Листание VimAwesome.com или чтение нескольких строк на странице помощи может очень сильно повысить чью-то эффективность. Большинство плагинов и настроек конфигурации появились у меня из-за раздражения и мыслей «Должен быть способ сделать это лучше».