Comments 3
Использую вим каждый день, как основной инструмент разработки, и на сколько я люблю сам сам, на столько же я ненавижу вимскрипт.
Это дитя, взращённое паскалем, и рождённое по пьяни от фортрана с коболом рано или поздно прикончит вим. Потому что большая часть силы вима в плагинах, а плагины должны развиваться, обновляться и писаться новые. Но делать это на вимскрипте — врагу не пожелаешь. Писал на нём плагин, и эту боль и страдания я буду ещё долго помнить.
Это дитя, взращённое паскалем, и рождённое по пьяни от фортрана с коболом рано или поздно прикончит вим. Потому что большая часть силы вима в плагинах, а плагины должны развиваться, обновляться и писаться новые. Но делать это на вимскрипте — врагу не пожелаешь. Писал на нём плагин, и эту боль и страдания я буду ещё долго помнить.
У Vim есть множество интерфейсов с другими языками. И Bram нормально принимает доработки к ним, если вы их напишете.
Это не значит, что всё идеально: не хватает двух вещей:
Без первого писать всё так же будет нелегко, в нынешней стадии интерфейсы отнюдь не идеальны. Поддержка Python, насколько я знаю, сделана на сейчас лучше всего (после моего патча, добавляющего pyeval()/py3eval() и vim.bindeval(), до того лучше было у lua), но моей единственной целью на момент написания было избавление от весьма прожорливой сериализации/десериализации, являвшейся единственным способом вернуть данные обратно в VimL.
Без второго будет сложно делать первое. При написании патча, к примеру, несколько static функций из eval.c перестали быть таковыми. В интерфейсе с lua они, кстати, почему‐то были просто скопированы из eval.c и уже устарели.
Идеальной реализацией второго, по моему мнению, может быть такая, при которой VimL станет таким же дополнением, как и Python. Но это работа, сопоставимая по сложности с написанием Vim с нуля.
Это не значит, что всё идеально: не хватает двух вещей:
- Этих самых доработок
- Официального C API
Без первого писать всё так же будет нелегко, в нынешней стадии интерфейсы отнюдь не идеальны. Поддержка Python, насколько я знаю, сделана на сейчас лучше всего (после моего патча, добавляющего pyeval()/py3eval() и vim.bindeval(), до того лучше было у lua), но моей единственной целью на момент написания было избавление от весьма прожорливой сериализации/десериализации, являвшейся единственным способом вернуть данные обратно в VimL.
Без второго будет сложно делать первое. При написании патча, к примеру, несколько static функций из eval.c перестали быть таковыми. В интерфейсе с lua они, кстати, почему‐то были просто скопированы из eval.c и уже устарели.
Идеальной реализацией второго, по моему мнению, может быть такая, при которой VimL станет таким же дополнением, как и Python. Но это работа, сопоставимая по сложности с написанием Vim с нуля.
Предельно восхищён и рад появлению такой мощной статьи от нового вимера, давненько не было ничего подобного.
Снимаю шляпу!
Снимаю шляпу!
Sign up to leave a comment.
Некоторые особенности VimL