Оглавление
- Введение (vim_lib)
- Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
- Уровень проекта и файловая система (vim_prj, nerdtree)
- Snippets и шаблоны файлов (UltiSnips, vim_template)
- Компиляция и выполнение чего угодно (vim-quickrun)
- Работа с Git (vim_git)
- Деплой (vim_deploy)
- Тестирование с помощью xUnit (vim_unittest)
- Библиотека, на которой все держится (vim_lib)
- Другие полезные плагины
Как можно назвать редактор удобным, если он не умеет запускать то, что мы программируем? Особенностью описываемого мной в данной статье плагина, является возможность запуска чего угодно, будь то программный код, plantUML, LaTeX, Less и всего, что можно написать и запустить. Плагин vim-quickrun может показаться довольно запутанным и сложным, не смотря на прекрасную документацию, потому я решил коротко осветить его в этой статье, дабы вы могли быстрее начать им пользоваться.
Компиляция и запуск редактором
Конечно средствами одного лишь редактора Vim не получится скомпилировать и/или запустить код, который мы в нем пишем. Для этого нам нужны сторонние утилиты, компиляторы и средства просмотра результата (на пример браузер, PDF читалка и т.д.). Плагин vim-quickrun позволяет определить набор инструментов, которые будут применяться к текущему файлу редактора с целью его компиляции и визуализации результата. Плагин довольно гибкий, что позволяет работать с любыми языками, если в системе установлены подходящие утилиты, конечно.
Определение типа
Плагин использует свойство filetype редактора Vim для определения типа запускаемого (обрабатываемого) файла. На практике это позволяет, на пример, работая с Web-проектом запустить в редакторе как PHP скрипт, так и скомпилировать Less файл и посмотреть результирующий CSS. Удобно, не правда ли?
Конфигурация
Плагин включает множество готовых решений для различных языков. Так, большинство современных ЯП компилируются и запускаются плагином «прямо из коробки» (при наличии соответствующих компиляторов и интерпретаторов). Это позволяет нам установить плагин и тут же начать им пользоваться, но кода мы сталкиваемся с более редкими языками, приходится немного «поколдовать». Для «колдовства» используется переменная редактора g:quickrun_config, которую следует инициализировать конфигурацией. Важно, что наша конфигурация всего навсего дополнит стандартную и нам не придется настраивать плагин для всех языков.
Для конфигурации плагина необходимо:
- Определить компилятор/интерпретатор плагина с помощью свойства command
- Определить команды, выполняющие пред- и постусловия с помощью свойства exec
- Определить команду, отвечающую за визуализацию результата, с помощью свойства outputter
Вот несколько примеров:
let g:quickrun_config = {
\ 'markdown': {
\ 'outputter': 'browser',
\ },
\}
let g:quickrun_config = {
\ 'tex': {
\ 'command': 'pdflatex',
\ 'exec': ['%c -synctex=1 -interaction=nonstopmode "%S:t:r.tex"', 'evince "%S:r.pdf"', 'rm "%S:t:r.pdf" "%S:t:r.aux" "%S:t:r.log" "%S:t:r.synctex.gz"'],
\ },
\}
let g:quickrun_config = {
\ 'plantuml': {
\ 'exec': ['java -jar ~/bin/plantuml.jar %S:p:h', 'display %S:p:r.png', 'rm %S:p:r.png'],
\ 'outputter': 'null',
\ },
\}
Как можно заметить, свойство outputter больше служит как stdout, а exec может выступать в качестве command, все зависит от задачи.
Пока все
Чтобы скомпилировать и запустить текущий файл используется команда :QuickRun. Постоянно набирать ее не очень удобно, потому советую определить псевдоним в вашем .vimrc файле.
nmap <F9> :w<CR>:QuickRun<CR>
Статья оказалась не очень большой, но не стоит расстраиваться, впереди еще много интересного!
Комментарии (28)
awhiler
26.06.2015 10:26+3А вот вам занятный факт, который все объясняет
The keyboard used by the designer of vi had esc next to Q and arrows printed on hjkl
Cheater
26.06.2015 11:22+1Чем это лучше встроенных средств? (:compiler, :make)
Delphinum Автор
26.06.2015 12:42+1Да практически ничем, разве что очередной слой абстракции, который можно конфигурировать в виде плагина.
poxu
26.06.2015 12:42compiler и make не успевают за техническим прогрессом. Для полноценной сборки и прогона тестов нужно выполнить несколько произвольных консольных команд.
poxu
26.06.2015 12:43А асинхронность есть в этом решении?
Delphinum Автор
26.06.2015 12:45На сколько я знаю, там нет никакой асинхронности. Жмякаете :QuickRun и ждете результата. Для компиляции целого проекта с не одной сотней файлов, лучше использовать другой подход, данный же плагин расчитан на быструю компиляциюю и просмотр результата.
poxu
26.06.2015 12:57Ну у меня сейчас запуск тестов. Просто, чтобы убедиться, что не сломал чего случайно. Тут либо планировщиком его регулярно запускать, либо асинхронным вызовом консольной команды из vim. Я выбрал второе, но думал, может какие ещё варианты есть.
Delphinum Автор
26.06.2015 13:22В Vim нет никакой асинхронности, оттого и пляшем.
Полные тесты я запуская пару раз в день с помощью vim_unittest, а конкретные классы тестирую чаще. И в том и другом случае асинхронность мне не пригождалась, ждать приходится не больше 5 секунд.
JagaJaga
26.06.2015 20:18github.com/osyo-manga/vim-watchdogs
Вот асинхронный плагин проверки синтаксиса. Тот же syntastic тормозит, а этот нет.Delphinum Автор
26.06.2015 21:54Почему вы решили, что он асинхронный?
JagaJaga
27.06.2015 00:161) Это написано в описании.
2) Я его использую :)Delphinum Автор
27.06.2015 00:20Ну так в описании много чего может быть написано. Глянул плагин, не увидил в нем асинхронности. Судя по всему, там используется Perl, для реализации асинхронного поведения, а это не есть Vim-асинхронность.
roman_kashitsyn
26.06.2015 16:01+1В vim сложно делать асинхронные вещи, там нет нормальных механизмов для выполнения работы в бэкграунде. NeoVim по сути начался с попыток исправить этот недостаток.
В Emacs, кстати, такой проблемы нет :)poxu
26.06.2015 16:13Я слышал об этом. Даже хочу попробовать с Emacs недельки две, попробовать асинхронность, но как-то не решаюсь.
BelBES
26.06.2015 21:47В Emacs, кстати, такой проблемы нет :)
Ну это вы слишком оптимистичны:) В emacs проблем с асинхронным выполнением команд тоже вагон и тележка)
Увы, но у современных редакторов аля sublime в этом плане дела обстоят намного лучше.roman_kashitsyn
26.06.2015 22:55В emacs проблем с асинхронным выполнением команд тоже вагон и тележка)
Конечно, проблемы есть, но как минимум можно делать что-нибудь полезное, пока идёт длинная компиляция. Ну и принципиально возможен, к примеру, comint — интерактивное взаимодействие с интерпретатором, выполняющимся в дочернем процессе.
Так что в общем дела ощутимо лучше.Delphinum Автор
26.06.2015 23:54А зачем долгую компиляцию выполнять средствами редактора?
roman_kashitsyn
27.06.2015 01:00Чтобы в случае неудачи можно было быстро прыгать по ошибкам.
Delphinum Автор
27.06.2015 13:44А с использованием сторонних систем для долгой компиляции прыгать по ошибкам не выйдет?
roman_kashitsyn
27.06.2015 13:49Но зачем мне использовать сторонние системы, если я могу запускать M-x compile и смотреть всё не выходя из Emacs?
Delphinum Автор
27.06.2015 14:08+1Может потому, что Emacs (Vim) это не операционная система, а текстовый редактор (пусть даже он умеет варить кофе)?
roman_kashitsyn
27.06.2015 15:35Может потому, что Emacs (Vim) это не операционная система, а текстовый редактор
Странное утрверждение для того, кто пишет плагины для компиляции проекта из редактора. О каком внешнем инструменте идёт речь? Как именно я должен его использовать? Как интегрировать результат его работы в сессию моего редактора?
Тот же vim имеет удобный quickfix, единственное отличие — vim из коробки не умеет компилировать в бэкграунде.
К слову, «длинная» компиляция для меня — пара минут. Это достаточное время, чтобы потерять интерес к присходящему и отвлечься на какую-нибудь почту, потеряв время. Вместо этого я мог бы запусть компиляцию с тестами и разбираться в коде дальше, время от времени поглядывая на лог в соседнем окне.
Более того — можно начать разбирать ошибки компиляции до того, как она завершилась полностью.Delphinum Автор
27.06.2015 18:18Странное утрверждение для того, кто пишет плагины для компиляции проекта из редактора
Я не писал плагинов для компиляции проекта из редактора, вы ошиблись.
О каком внешнем инструменте идёт речь?
О том, который будет компилировать, тестировать и разворачивать создаваемую программу на пример. Компиляция и исполнение через редактор должна быть быстрой и частой, если нужно компилировать более нескольких секунд, то вам нужен другой инструмент.
Как интегрировать результат его работы в сессию моего редактора?
Обычно компилятор можно заставить создавать файл с ошибками компиляции. В вашем редакторе будет достаточно прочитать этот файл с помощью специализированных функций.
Более того — можно начать разбирать ошибки компиляции до того, как она завершилась полностью
Вы путаете асинхронный запуск компилятора из редактора и получение информации об ошибках. Вам никто не мешает запустить компиляцию асинхронно и открыв stderr в отдельном буфере подглядывать в него. Просто не вижу смысла в асинхронном Vim для таких целей, с этим прекрасно справится и используемая ОС.
roman_kashitsyn
28.06.2015 00:55если нужно компилировать более нескольких секунд, то вам нужен другой инструмент
Очень спорное утверждение. К примеру, редкий C++-проект компилируется несколько секунд, даже при инкрементальной сборке.
Ок, если вы считаете это идеологически неправильным — это ваше право. Я же буду продолжать использовать свой редактор без лишних движений, временных файлов и переключений контекста.Delphinum Автор
28.06.2015 01:00Я же буду продолжать использовать свой редактор без лишних движений, временных файлов и переключений контекста
Я вас и не заставляю делать иначе, просто утверждаю, что с этим прекрасно справляется ОС, которая для того и создана.
Majestio
«У редактора vi есть два режима — в одном он пищит, а во втором он все портит» (С)