company_banner

Vim спустя 15 лет

https://statico.github.io/vim3.html
  • Перевод


Мои предыдущие посты об использовании 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 или чтение нескольких строк на странице помощи может очень сильно повысить чью-то эффективность. Большинство плагинов и настроек конфигурации появились у меня из-за раздражения и мыслей «Должен быть способ сделать это лучше».

Mail.ru Group
1733,00
Строим Интернет
Поделиться публикацией

Похожие публикации

Комментарии 40

    +3

    Теги не читают, по ним ищут. Спасибо за перевод.

      0
      Предпочитаю терминал, но есть ряд веских причин, чтобы выбрать отдельное приложение Vim:

      5. ...

      6. По форме курсора в GUI приложении легко определить текущий режим, не опуская взгляд на строку состояния. :)
      +3
      Я один начал смотреть комикс слева — направо, а не сверху — вниз?
        +4

        Справа налево

        +3
        :q!

        # nanoХватит это терпеть :)
          0
          Если вам нужна настоящая цветовая схема Solarized вместо того кощунства, которое получилось при сжатии Solarized до 256 цветов.

          Перешел на терминалы с поддержкой 24-битного цвета (в частности, iTerm2) и всем рекомендую.
            0
            Ctrlp тоже умеет в ag. Смысл ставить fzf, чтобы использовать тот же ag?
              0

              Как минимум одно из двоих то поставить нужно.


              При прочих равных с ag — Фзф типа в ряде случаев быстрее

                0

                fzf быстрое и асинхронное

                0

                Плагин… Плагин… Плагин…


                Советую посмотреть ролик https://youtu.be/XA2WjJbmmoM
                Он уже довольно старый, но хорошо отображает, насколько вим полноценен и самостоятелен, и насколько хорошо можно обходиться без горы плагинов на каждую простейшую задачу

                  0
                  Я использую 57 плагинов. Все они необходимы и встроенного функционала в виме нет. Именно такого, который есть в плагинах. Ага, можно конечно пользоваться set path+=**, но когда проект чуть больше, чем хеловорлд, становится неуютно этим пользоваться. Всё остальное по аналогии.
                  +4

                  Шутки шутками, но пару дней назад я своими руками гуглил "как выйти из vim".


                  Хтонический ужас этот ваш vim. Текстовый редактор, сделанный садистами для мазохистов.

                    0

                    Шутки шутками, но я понимаю, что в 90-м году редактор vi еще не умел показывать подсказки, а люди могли не знать сочетаний клавиш. Но сегодня вим при запуске без файла показывает help. В случае нажатия ctrl+c — пишет "Type :quit to exit Vim". То, что кто-то неосилил вим — не делает его "Текстовый редактор, сделанный садистами для мазохистов". Тут проблема несколько в другом :)

                      0
                      В современном мире более-менее неплохо достигнут консенсус относительно того, что должен представлять собой текстовый редактор. В частности, если пользователь делает «Type :quit», у него в позиции курсора должно напечататься «:quit». Без вариантов.

                      Вещи, которыми мы пользуемся, должны быть удобными, практичными и простыми в понимании и использовании. Особенно это касается инструментов, используемых профессионалами. Удобство пылящегося в шкафу горожанина топора никого не волнует, но юзабильность топора, которым работает каждый день плотник, должна быть доведена до совершенства. У нас же странная ситуация: для «привет, как дела» нормальные текстовые редакторы, а для редактирования конфигов серверов — [censored].

                      Можно сделать велосипед, которому для того, чтобы ехать вперёд, нужно крутить педали назад, а для того, чтобы повернуть направо, нужно будет крутить руль налево. И будут привыкшие к этому ужасу и настаивающие на том, что крутые чуваки только таким пользоваться и должны. Потому что иначе не круто. Но что-то мне подсказывает, что объяснения таким феноменам нужно искать не в рациональных мотивах, а в банальном стокгольмском синдроме.
                        0

                        Так способ редактирования в Вим (режимы) именно что доведен до совершенства ;)

                          0
                          Но что-то мне подсказывает, что объяснения таким феноменам нужно искать не в рациональных мотивах, а в банальном стокгольмском синдроме.

                          Стокгольмский синдром возникает, если человек что-то делает против своей воли, вынужденно. Любителей вима никто не заставляет им пользоваться.

                          –1
                          vim — это редактор для тех, кто привык к vim.
                          но меня необходимость что-то печатать, чтобы добраться до того же буфера, просто вымораживает.
                          я знаю, что у многих программистов есть эта манера «мы будем делать работу со своей скоростью, остальные подождут» и им не лениво делать ее дольше, пренебрегая личным\семейным временем. Как только по задаче будут стоять короткие сроки и заслонка будет падать в 17:30, так сразу начнется IntelliJ idea и прочий JetBrains.

                          57 плагинов, выше чувак пишет… простите, сколько времени он потратил на поиск и установку 57 плагинов? Я этот ваш Sublime не стал ставить, так как там даже распечатка кода — плагин.
                            0

                            Если вас что-то вымораживает, зачем читаете статьи про вим? Вас кто-то заставляет им пользоваться?

                              –1
                              Почему вы мне отказываете в праве убить время на статью про вим, если установка 60 плагинов не вызывает у вас ни тени протеста?

                              Несмотря на то, что вы, или кто-то, довольно резво понизил мне карму для поддержки своей точки зрения, но я все измеряю в терминах эффективности. Обилие кликов для простых операций, колоссальные кустомизации — это все время. Хороший программист зарабатывает что-то навроде 1000 долларов в неделю, которую, например, я бы явно потратил на все эти 57 плагинов. Конечно, деньги в масштабах даже года маленькие, но если он сегодня ставит 57 плагинов, то завтра — вместо выдачи результата — он может угрохать еще куда-то столько же…
                                0

                                Это был вопрос, а не требование. Установка необходимого количества плагинов — это сознательный выбор каждого человека. Вот только в пресловутой идее у меня по умолчанию 32 плагина и это вас почему-то не смущает

                                  –1
                                  Вопрос выглядел как завуалированный намек «тут не приветствуется критика известных отрицательных сторон юзабилити великого редактора».

                                  Пришло на почту, вот и прочитал. Можно подумать, котиков на 9gag все смотрят «зачем-то» ;)

                                  Просто задаюсь вопросом, насколько продуктивна работа в данном редакторе — и на что еще готов отвлечься от дела программист, которому не лень собирать из плагинов обычный функционал.
                                    0

                                    Завуалированый намек произошел у вас в голове, мне просто было любопытно, зачем вам тратить свое время на ерунду, типа текущей статьи, вы ведь деньги зарабатываете? Как же продуктивность работы? Почему вы отвлекаетесь на эту статью? Могли бы уже таску закрыть с помощью идеи.

                                      –1
                                      Краткие перерывы вполне допустимы. Таску, кстати, вполне себе делаю и еще двух человек сориентировал на их работу сегодня
                                        0

                                        Вот кто-то делает краткие перерывы на чтение статтей, а кто-то на настройку любимого инструмента, который повышает комфорт и удобство работы. Терпимее надо быть с другими людьми, а не мне неудобно — никому не удобно

                                          –1
                                          Терпимее надо быть с другими людьми

                                          • я вообще только за себя писал, а других людей не трогал.
                                          • ваша собственная терпимость к другим людям проиллюстрирована «допросом» про то, зачем я пишу комментарии и минусом в карму. Но я в людях и так давно разочаровался, так что ничего нового не увидел.
                                            0

                                            Я вам не ставил минусов


                                            я вообще только за себя писал, а других людей не трогал.

                                            57 плагинов, выше чувак пишет… простите, сколько времени он потратил на поиск и установку 57 плагинов?
                                            я знаю, что у многих программистов есть эта манера «мы будем делать работу со своей скоростью, остальные подождут» и им не лениво делать ее дольше, пренебрегая личным\семейным временем.
                              0
                              Про «печатать чтобы добраться до буфера».
                              Автор статьи подразумевает что если человек пользуется Вимом то он умеет назначать горячие клавиши на «многобуквенные» команды.

                              Более того — если бы автор привел свои хоткеи вместо полных команд — то было бы совершенно непонятно.
                                –1
                                Вам не кажется, что гигантская по трудозатратам нужда в донастройке vim — это прошлый век?

                                Сколько времени у него должно уйти на настройку хоткеев? Еще денек к той неделе, которая потребуется ему на 57 плагинов?
                                  0
                                  Вам не кажется, что гигантская по трудозатратам нужда в донастройке vim — это прошлый век?

                                  А что нынче не надо под себя донастраивать, если хочешь удобства?

                                    0
                                    Ну допустим IntelliJ не надо. Разве что печать на клавиши повесить
                                      0

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

                                        0
                                        У IntelliJ есть несколько альтернативных настроек, которые кто то сделал и вам предлагают их выбрать при установке. И там тоже не на все есть уже хоткеи.

                                        Ровно также есть готовые настройки и для Vim. Они тоже могут подтягиваться автоматом из интернета как и плагины для IntelliJ к примеру
                                      0
                                      Я переформулирую доводы тех, кого слышал (и с кем согласен):
                                      1. При достижении определенного уровня умения, vim дает прибавку к скорости работы (исследований на этот счет я не слышал, но все кто им пользуются так утверждают. Доводы у каждого могу быть совершено разные)
                                      Примеры доводов
                                      1. Не надо переключаться на стрелочки
                                      2. Поддержка любого языка программирования
                                      3. Быстрая загрузка самого вима на любой системе и быстрая загрузка любых, по размеру, файлов.
                                      4. Быстрая установка и настройка вима с нуля со всеми своими любимыми плагинами на любой системе
                                      5. Работа через SSH
                                      6. Поддержка макросов: жмете «q+[любая буква]», делаете что нужно, потом на "@+[эта буква]" можете все повторить. Например легко превратить из print('val=', val) в log.debug('val=' + val) 10 строчек. Причем для этого есть не только макросы, а еще много разных путей и способов. Большинство из них быстрее, чем «заменить на» с помощью мышки. Пусть на несколько секунд, но быстрее.
                                      7. Если вас действительно интересует, каким образом люди повышают производительность с помощью Vim, полистайте тут(en), или вот ответы на прямой вопрос в чем выгода учить vim?(en)
                                      8. На самом деле на этот ваш вопрос не отвечал только ленивый, и количество статей и ответов на эту тему давно стремится в бесконечность.

                                      2. Овладев vim-ом в должной степени во время работы испытываешь «кайф», когда перестаешь думать о нажатиях клавиш, а просто думешь о том, что тебе нужно.
                                      Лирическое отсупление
                                      Например, ты просто смотришь на букву, пальцы автоматически нажимают несколько клавиш, и вот уже курсор там. Еще пара клавиш (которые нажимаются без участия мозга), ты поставил закладку, прыгнул в функцию, что-то подредактировал, запустил программу, увидел результат, прыгнул на метку и поменял какое-то значение. Всё это автоматически, глядя только на экран и думая только о том, что тебе нужно сделать. Это как ощущение управления автомобилем в гонке: ты уже не думаешь какую педаль нажимать, какую скорость втыкать, ты смотришь на дорогу и соперников, все твое внимание находится там. Если во время работы приходится убирать руки на мышку, то это воспринимается примерно как отвернутся от дороги во время гонки и что-то искать на заднем сиденье.

                                      Отвечая на ваш вопрос, сколько времени он на это потратил не так важно, поскольку, в конечном итоге, вим дает прибавку к скорости, то есть затраты на его настройку похожи на затраты для овладения слепым методом печати. Или вы считаете изучение слепой печати тоже бесполезным проведением времени?
                                      Все же, с одной стороны, я с вами согласен. Неправильно приходить на работу и копаться в плагинах и настройках вима несколько часов (и я уверен, никто этого не делает). С другой стороны, нужно понимать, что не все так просто в жизни: если вы напишите за 1 час плагин к виму, который потом сэкономит вам суммарно 2 часа рабочего времени, то почему нет?
                                      И позвольте вам ответный вопрос: почему до сих пор такое большое количество программистов используют текстовые редакторы вместо IDE? Вы всерьез утверждаете, что это просто вопрос привычки?
                                        0
                                        Готовые хоткеи кем то уже созданные — нужно запомнить.
                                        Свои — нужно придумать.
                                        Что проще?

                                        По сложность — вообще не понял. Задание того или иного хоткея — это штатная функциональность редактора. Для этого не нужно писать свой скрипт.

                                        Для более «современного» по вашим меркам редактора команда звучала бы так «меню Edit/Select All». Что тоже громоздко.

                                        Если же вы предпочитаете пользоваться тем хоткеем Ctrl+A который за вас кто то придумал — вы ровно также можете воспользоваться и для Vim чужой дефолтной настройкой.

                                        Меня например тоже вполне устраивает для языка Go великолепные настройки vim-go, которые придумал (и продолжает дополнять и развивать) Аслан не помню по фамилии как его
                                0

                                Думаю что нелюбовь к большому количеству плагинов вызвана именно отсутствием асинхры в vim < 8. Те же линтеры превращали работу в ад, особенно на синтаксически сложных языках, типо Ruby.

                                  0
                                  Fzf для windows не особо полезен, как я понял? Час бился над ним, подключил это чудо поиска к vim с помощью fzf.vim, всё равно толкового ничего не вышло: почти все мои файлы находятся на диске D, но fzf упорно ищет только С. Как поменять — непонятно. Полноценной инструкции по установке и настройке в Windows нету. Можно сказать только экспериментальный режим. Открывается в отдельном окне, поддержка внутри вима возможна только для консольной версии. В общем помучался, поигрался, не оценил. Когда в будущем перейду на Linux, попробую еще раз, а пока очень жаль что ничего не вышло.
                                  За остальные плагины спасибо, особенно ale понравился, Syntastic с pylint даже на 500 строках кода подтармаживал каждый раз при сохранении файла.
                                    0
                                    Попробуйте LeaderF, он так же будет полезен тем, кто пользуется gui vim.
                                      0
                                      Я думал CtrlP будет достаточно, но, почему-то, он не увидел появления новых файлов в папке. Спасибо, LeaderF действительно подошел лучше.
                                        0
                                        просто ты достаточно ленив, чтобы прочитать документацию к ctrlp

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое