Vim по полной: Компиляция и выполнение чего угодно

    Оглавление


    1. Введение (vim_lib)
    2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
    3. Уровень проекта и файловая система (vim_prj, nerdtree)
    4. Snippets и шаблоны файлов (UltiSnips, vim_template)
    5. Компиляция и выполнение чего угодно (vim-quickrun)
    6. Работа с Git (vim_git)
    7. Деплой (vim_deploy)
    8. Тестирование с помощью xUnit (vim_unittest)
    9. Библиотека, на которой все держится (vim_lib)
    10. Другие полезные плагины

    Как можно назвать редактор удобным, если он не умеет запускать то, что мы программируем? Особенностью описываемого мной в данной статье плагина, является возможность запуска чего угодно, будь то программный код, plantUML, LaTeX, Less и всего, что можно написать и запустить. Плагин vim-quickrun может показаться довольно запутанным и сложным, не смотря на прекрасную документацию, потому я решил коротко осветить его в этой статье, дабы вы могли быстрее начать им пользоваться.

    Компиляция и запуск редактором


    Конечно средствами одного лишь редактора Vim не получится скомпилировать и/или запустить код, который мы в нем пишем. Для этого нам нужны сторонние утилиты, компиляторы и средства просмотра результата (на пример браузер, PDF читалка и т.д.). Плагин vim-quickrun позволяет определить набор инструментов, которые будут применяться к текущему файлу редактора с целью его компиляции и визуализации результата. Плагин довольно гибкий, что позволяет работать с любыми языками, если в системе установлены подходящие утилиты, конечно.

    Определение типа


    Плагин использует свойство filetype редактора Vim для определения типа запускаемого (обрабатываемого) файла. На практике это позволяет, на пример, работая с Web-проектом запустить в редакторе как PHP скрипт, так и скомпилировать Less файл и посмотреть результирующий CSS. Удобно, не правда ли?

    Конфигурация


    Плагин включает множество готовых решений для различных языков. Так, большинство современных ЯП компилируются и запускаются плагином «прямо из коробки» (при наличии соответствующих компиляторов и интерпретаторов). Это позволяет нам установить плагин и тут же начать им пользоваться, но кода мы сталкиваемся с более редкими языками, приходится немного «поколдовать». Для «колдовства» используется переменная редактора g:quickrun_config, которую следует инициализировать конфигурацией. Важно, что наша конфигурация всего навсего дополнит стандартную и нам не придется настраивать плагин для всех языков.

    Для конфигурации плагина необходимо:
    • Определить компилятор/интерпретатор плагина с помощью свойства command
    • Определить команды, выполняющие пред- и постусловия с помощью свойства exec
    • Определить команду, отвечающую за визуализацию результата, с помощью свойства outputter

    Вот несколько примеров:
    Markdown
    let g:quickrun_config = {
    \ 'markdown': {
    \   'outputter': 'browser',
    \ },
    \}
    


    LaTeX
    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"'],
    \ },
    \}
    


    PlantUML
    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 :w:QuickRun

    Статья оказалась не очень большой, но не стоит расстраиваться, впереди еще много интересного!
    Share post

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 28

      –4
      «У редактора vi есть два режима — в одном он пищит, а во втором он все портит» (С)
        +3
        А вот вам занятный факт, который все объясняет

        image

        The keyboard used by the designer of vi had esc next to Q and arrows printed on hjkl
          +1
          Чем это лучше встроенных средств? (:compiler, :make)
            +1
            Да практически ничем, разве что очередной слой абстракции, который можно конфигурировать в виде плагина.
              0
              compiler и make не успевают за техническим прогрессом. Для полноценной сборки и прогона тестов нужно выполнить несколько произвольных консольных команд.
              0
              А асинхронность есть в этом решении?
                0
                На сколько я знаю, там нет никакой асинхронности. Жмякаете :QuickRun и ждете результата. Для компиляции целого проекта с не одной сотней файлов, лучше использовать другой подход, данный же плагин расчитан на быструю компиляциюю и просмотр результата.
                  0
                  Ну у меня сейчас запуск тестов. Просто, чтобы убедиться, что не сломал чего случайно. Тут либо планировщиком его регулярно запускать, либо асинхронным вызовом консольной команды из vim. Я выбрал второе, но думал, может какие ещё варианты есть.
                    0
                    В Vim нет никакой асинхронности, оттого и пляшем.
                    Полные тесты я запуская пару раз в день с помощью vim_unittest, а конкретные классы тестирую чаще. И в том и другом случае асинхронность мне не пригождалась, ждать приходится не больше 5 секунд.
                      0
                      github.com/osyo-manga/vim-watchdogs
                      Вот асинхронный плагин проверки синтаксиса. Тот же syntastic тормозит, а этот нет.
                        0
                        Почему вы решили, что он асинхронный?
                          0
                          1) Это написано в описании.
                          2) Я его использую :)
                            0
                            Ну так в описании много чего может быть написано. Глянул плагин, не увидил в нем асинхронности. Судя по всему, там используется Perl, для реализации асинхронного поведения, а это не есть Vim-асинхронность.
                              0
                              Ну так ведь она есть в виде реализации на перле, так что спорно говорить об отсутствии асинхронности.
                                0
                                В Vim нет никакой асинхронности

                                Кажись вам показалось Perl вместо Vim ;)
                      +1
                      В vim сложно делать асинхронные вещи, там нет нормальных механизмов для выполнения работы в бэкграунде. NeoVim по сути начался с попыток исправить этот недостаток.
                      В Emacs, кстати, такой проблемы нет :)
                        0
                        Я слышал об этом. Даже хочу попробовать с Emacs недельки две, попробовать асинхронность, но как-то не решаюсь.
                          0
                          В Emacs, кстати, такой проблемы нет :)

                          Ну это вы слишком оптимистичны:) В emacs проблем с асинхронным выполнением команд тоже вагон и тележка)
                          Увы, но у современных редакторов аля sublime в этом плане дела обстоят намного лучше.
                            0
                            В emacs проблем с асинхронным выполнением команд тоже вагон и тележка)

                            Конечно, проблемы есть, но как минимум можно делать что-нибудь полезное, пока идёт длинная компиляция. Ну и принципиально возможен, к примеру, comint — интерактивное взаимодействие с интерпретатором, выполняющимся в дочернем процессе.
                            Так что в общем дела ощутимо лучше.
                              0
                              А зачем долгую компиляцию выполнять средствами редактора?
                                0
                                Чтобы в случае неудачи можно было быстро прыгать по ошибкам.
                                  0
                                  А с использованием сторонних систем для долгой компиляции прыгать по ошибкам не выйдет?
                                    0
                                    Но зачем мне использовать сторонние системы, если я могу запускать M-x compile и смотреть всё не выходя из Emacs?
                                      +1
                                      Может потому, что Emacs (Vim) это не операционная система, а текстовый редактор (пусть даже он умеет варить кофе)?
                                        0
                                        Может потому, что Emacs (Vim) это не операционная система, а текстовый редактор


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

                                        Тот же vim имеет удобный quickfix, единственное отличие — vim из коробки не умеет компилировать в бэкграунде.
                                        К слову, «длинная» компиляция для меня — пара минут. Это достаточное время, чтобы потерять интерес к присходящему и отвлечься на какую-нибудь почту, потеряв время. Вместо этого я мог бы запусть компиляцию с тестами и разбираться в коде дальше, время от времени поглядывая на лог в соседнем окне.
                                        Более того — можно начать разбирать ошибки компиляции до того, как она завершилась полностью.
                                          0
                                          Странное утрверждение для того, кто пишет плагины для компиляции проекта из редактора

                                          Я не писал плагинов для компиляции проекта из редактора, вы ошиблись.

                                          О каком внешнем инструменте идёт речь?

                                          О том, который будет компилировать, тестировать и разворачивать создаваемую программу на пример. Компиляция и исполнение через редактор должна быть быстрой и частой, если нужно компилировать более нескольких секунд, то вам нужен другой инструмент.

                                          Как интегрировать результат его работы в сессию моего редактора?

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

                                          Более того — можно начать разбирать ошибки компиляции до того, как она завершилась полностью

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

                                            0
                                            если нужно компилировать более нескольких секунд, то вам нужен другой инструмент

                                            Очень спорное утверждение. К примеру, редкий C++-проект компилируется несколько секунд, даже при инкрементальной сборке.

                                            Ок, если вы считаете это идеологически неправильным — это ваше право. Я же буду продолжать использовать свой редактор без лишних движений, временных файлов и переключений контекста.
                                              0
                                              Я же буду продолжать использовать свой редактор без лишних движений, временных файлов и переключений контекста

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

                  Only users with full accounts can post comments. Log in, please.