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

Вкратце:

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

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

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

FZF

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

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

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

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

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

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

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

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

Вот кусок кода из моего .zshrc ^[13]. Когда 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. Но теперь всё изменилось! Поддержку добавили недавно ^[14] с помощью новых нативных терминалов в Vim 8 ^[15]. Работает хорошо, но гораздо медленнее, чем терминал в большой кодовой базе (~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 ^[16], но это заблуждение, потому что ag.vim устарел ^[17], но ack.vim поддерживает и ack, и ag.

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

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

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

Когда результаты появятся в окне QuickFix, самый простой способ их использовать — переместить курсор и нажать Enter для открытия результата. Также для навигации по списку есть команды :cnext и :cprev, и я пытался найти подходящие кроссплатформенные комбинации клавиш, но не нашёл. Затем я открыл для себя vim-unimpaired ^[19], добавляющий полезные биндинги вроде [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 несколько раз, тем самым перепрыгивая обратно по списку переходов ^[20], словно жму кнопку «Назад» в браузере. В другие разы использую; для поднятия списка из буфера и поиска там оригинального файла. Но теперь, когда я об этом задумался, возможно, изменю на O глобальную отметку (global mark ^[21]) в своём биндинге Meta-k, так что 'O будет всегда возвращать меня туда, откуда я начал.

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

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

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

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

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

Обычно я вношу изменения в 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 можно почитать здесь ^[27] и здесь ^[29].

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

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

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

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

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

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

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

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

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 стало управление асинхронными процессами ^[36]. Теперь, когда Vim может выполнять процессы в фоне, во владения Syntastic ^[37] вторгается новый хороший плагин ALE ^[38], асинхронно исполняющий линтеры. Больше не нужно ждать, пока ваш линтер выполнит работу при каждой записи файла. Я писал много Ruby-кода в Jruby, и там приходилось ощутимо долго ждать, пока линтер всё сделает, поэтому я выключил Syntastic. Но благодаря ALE я теперь могу включить линтинг при написании кода.

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

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

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

Git

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Автор: AloneCoder

Источник ^[74]