Как стать автором
Обновить

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

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

image

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Публикации

Истории