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

The keyboard used by the designer of vi had esc next to Q and arrows printed on hjkl

The keyboard used by the designer of vi had esc next to Q and arrows printed on hjkl
Чем это лучше встроенных средств? (:compiler, :make)
А асинхронность есть в этом решении?
На сколько я знаю, там нет никакой асинхронности. Жмякаете :QuickRun и ждете результата. Для компиляции целого проекта с не одной сотней файлов, лучше использовать другой подход, данный же плагин расчитан на быструю компиляциюю и просмотр результата.
Ну у меня сейчас запуск тестов. Просто, чтобы убедиться, что не сломал чего случайно. Тут либо планировщиком его регулярно запускать, либо асинхронным вызовом консольной команды из vim. Я выбрал второе, но думал, может какие ещё варианты есть.
В Vim нет никакой асинхронности, оттого и пляшем.
Полные тесты я запуская пару раз в день с помощью vim_unittest, а конкретные классы тестирую чаще. И в том и другом случае асинхронность мне не пригождалась, ждать приходится не больше 5 секунд.
Полные тесты я запуская пару раз в день с помощью vim_unittest, а конкретные классы тестирую чаще. И в том и другом случае асинхронность мне не пригождалась, ждать приходится не больше 5 секунд.
github.com/osyo-manga/vim-watchdogs
Вот асинхронный плагин проверки синтаксиса. Тот же syntastic тормозит, а этот нет.
Вот асинхронный плагин проверки синтаксиса. Тот же syntastic тормозит, а этот нет.
В vim сложно делать асинхронные вещи, там нет нормальных механизмов для выполнения работы в бэкграунде. NeoVim по сути начался с попыток исправить этот недостаток.
В Emacs, кстати, такой проблемы нет :)
В Emacs, кстати, такой проблемы нет :)
Я слышал об этом. Даже хочу попробовать с Emacs недельки две, попробовать асинхронность, но как-то не решаюсь.
В Emacs, кстати, такой проблемы нет :)
Ну это вы слишком оптимистичны:) В emacs проблем с асинхронным выполнением команд тоже вагон и тележка)
Увы, но у современных редакторов аля sublime в этом плане дела обстоят намного лучше.
В emacs проблем с асинхронным выполнением команд тоже вагон и тележка)
Конечно, проблемы есть, но как минимум можно делать что-нибудь полезное, пока идёт длинная компиляция. Ну и принципиально возможен, к примеру, comint — интерактивное взаимодействие с интерпретатором, выполняющимся в дочернем процессе.
Так что в общем дела ощутимо лучше.
А зачем долгую компиляцию выполнять средствами редактора?
Чтобы в случае неудачи можно было быстро прыгать по ошибкам.
А с использованием сторонних систем для долгой компиляции прыгать по ошибкам не выйдет?
Но зачем мне использовать сторонние системы, если я могу запускать M-x compile и смотреть всё не выходя из Emacs?
Может потому, что Emacs (Vim) это не операционная система, а текстовый редактор (пусть даже он умеет варить кофе)?
Может потому, что Emacs (Vim) это не операционная система, а текстовый редактор
Странное утрверждение для того, кто пишет плагины для компиляции проекта из редактора. О каком внешнем инструменте идёт речь? Как именно я должен его использовать? Как интегрировать результат его работы в сессию моего редактора?
Тот же vim имеет удобный quickfix, единственное отличие — vim из коробки не умеет компилировать в бэкграунде.
К слову, «длинная» компиляция для меня — пара минут. Это достаточное время, чтобы потерять интерес к присходящему и отвлечься на какую-нибудь почту, потеряв время. Вместо этого я мог бы запусть компиляцию с тестами и разбираться в коде дальше, время от времени поглядывая на лог в соседнем окне.
Более того — можно начать разбирать ошибки компиляции до того, как она завершилась полностью.
Странное утрверждение для того, кто пишет плагины для компиляции проекта из редактора
Я не писал плагинов для компиляции проекта из редактора, вы ошиблись.
О каком внешнем инструменте идёт речь?
О том, который будет компилировать, тестировать и разворачивать создаваемую программу на пример. Компиляция и исполнение через редактор должна быть быстрой и частой, если нужно компилировать более нескольких секунд, то вам нужен другой инструмент.
Как интегрировать результат его работы в сессию моего редактора?
Обычно компилятор можно заставить создавать файл с ошибками компиляции. В вашем редакторе будет достаточно прочитать этот файл с помощью специализированных функций.
Более того — можно начать разбирать ошибки компиляции до того, как она завершилась полностью
Вы путаете асинхронный запуск компилятора из редактора и получение информации об ошибках. Вам никто не мешает запустить компиляцию асинхронно и открыв stderr в отдельном буфере подглядывать в него. Просто не вижу смысла в асинхронном Vim для таких целей, с этим прекрасно справится и используемая ОС.
если нужно компилировать более нескольких секунд, то вам нужен другой инструмент
Очень спорное утверждение. К примеру, редкий C++-проект компилируется несколько секунд, даже при инкрементальной сборке.
Ок, если вы считаете это идеологически неправильным — это ваше право. Я же буду продолжать использовать свой редактор без лишних движений, временных файлов и переключений контекста.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Vim по полной: Компиляция и выполнение чего угодно