А оставшиеся 5, видимо, не могут быть покрыты в принципе.
Мне лично проще жить с более плохим автодополнением, чем настроить IDE под себя: слишком много придётся настраивать, причём значительная часть из этого «много» является либо одной из основных возможностей Vim, либо предоставляется чужими дополнениями с небольшой настройкой. Оставшееся написано самостоятельно.
Вот как раз у Vim одна из самых совершенных систем навигации внутри файла (за исключением штук вроде «перейти к объявлению», не работающих без дополнений). Никаких PageUp/PageDown, работа с Vim вообще не предполагает перемещение рук куда‐либо с основного блока клавиатуры.
Кроме того, зачастую нужно сделать «command|xclip -i» и затем нормально вставлять вывод команды куда угодно средней кнопкой мыши. Можно сразу отправить текст на pastebin. Если вывод длиннее одной строчки, а запуск команды два раза быстр и производит одинаковый текст, то в GUI это будет сложнее сделать. Отдельно про SO: у меня есть
alias +4='sed "s/^/ /" | xclip -i'
, в Vim можно сделать привязку для того же (а можно просто выделить текст и сделать «>gv>», затем вставить). Интересно услышать, как вы копируете код из GUI.
Есть огромная куча дополнений к Vim разной степени работоспособности для различных языков, предоставляющих возможность перехода к определению и интеллектуального автодополнения. Дополнения, использующие синтаксические анализаторы тоже есть, но VimL не даёт (точнее, требует медленных и неприглядных решений) довольно большого количества возможностей их интеграции.
Grep обычно делается из Vim, а не из консоли в этом случае, так переход к найденному можно осуществить гораздо быстрее.
16 символов в секунду — это 960 в минуту. Какое здесь «даже при»?
В Vim очень удобно использовать Command-T для открытия файлов. Впрочем, это не единственное дополнение на эту тему: есть также FuzzyFinder, Unity, ku, LustyExplorer, … А автодополнение файлов в Vim убого. Я как‐то сделал аналог автодополнения файлов в zsh (причём, в zsh автодополнение именно файлов оказалось несколько хуже), но Command-T оказался ещё удобнее, поэтому проект заглох несмотря на несколько очевидных проблем.
Относительно virtualenv: “workon env” не работает в Vim (в смысле, если запустить workon и затем Vim, встроенная поддержка python будет игнорировать виртуальное окружение, но запущенные из Vim команды игнорировать не будут). Приходится использовать github.com/jmcantrell/vim-virtualenv.
Я не говорил, что Mercurial — синоним этого понятия. Я сказал, что veracity напоминает Mercurial в большей степени, чем Git (поэтому мне было непонятно, почему в статье написано «схожая с Git»). Ни одно из перечисленных мною сходств не является необходимым для того, чтобы система называлась «DVCS».
# На исходниках git:
$ git mv ws.c wss.c
$ echo 1>wss.c
$ git add wss.c
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# deleted: ws.c
# new file: wss.c
#
$ git reset --hard HEAD
$ git mv ws.c wss.c
$ git commit -m 'ABC'
$ git diff --name-status HEAD^..HEAD
D ws.c
A wss.c
$ git diff --name-status -C HEAD^..HEAD
R100 ws.c wss.c
# На исходниках mercurial:
$ hg mv README README.md
$ echo 1>README.md
$ hg status -C
A README.md
README
R README
Git не сохраняет информацию о переименованиях, он смотрит на процент сходства. То же, что я говорил, просто это поведение по‐умолчанию у некоторых команд. Mercurial, наоборот, никогда не смотрит на сходство файлов.
Всё верно. Посмотрите git help diff, там есть ключи --find-renames, --find-copies, --find-copies-harder. Если бы git сохранял информацию о переименованиях, зачем бы были нужны такие ключи?
Формальное переименование файлов, возможность написания хуков на языке программирования, локальные номера ревизий, неизменность истории (если я правильно понял, что на сайте имеется ввиду под «immutability doctrine»), ветки, являющиеся свойством ревизии (а не просто указателями на конкретную ревизию как в git), команды вроде incoming/outgoing, heads, serve. Это всё подозрительно напоминает отнюдь не Git, а Mercurial.
У Vim есть множество интерфейсов с другими языками. И Bram нормально принимает доработки к ним, если вы их напишете.
Это не значит, что всё идеально: не хватает двух вещей:
Этих самых доработок
Официального C API
Без первого писать всё так же будет нелегко, в нынешней стадии интерфейсы отнюдь не идеальны. Поддержка Python, насколько я знаю, сделана на сейчас лучше всего (после моего патча, добавляющего pyeval()/py3eval() и vim.bindeval(), до того лучше было у lua), но моей единственной целью на момент написания было избавление от весьма прожорливой сериализации/десериализации, являвшейся единственным способом вернуть данные обратно в VimL.
Без второго будет сложно делать первое. При написании патча, к примеру, несколько static функций из eval.c перестали быть таковыми. В интерфейсе с lua они, кстати, почему‐то были просто скопированы из eval.c и уже устарели.
Идеальной реализацией второго, по моему мнению, может быть такая, при которой VimL станет таким же дополнением, как и Python. Но это работа, сопоставимая по сложности с написанием Vim с нуля.
Мне лично проще жить с более плохим автодополнением, чем настроить IDE под себя: слишком много придётся настраивать, причём значительная часть из этого «много» является либо одной из основных возможностей Vim, либо предоставляется чужими дополнениями с небольшой настройкой. Оставшееся написано самостоятельно.
Кроме того, зачастую нужно сделать «command|xclip -i» и затем нормально вставлять вывод команды куда угодно средней кнопкой мыши. Можно сразу отправить текст на pastebin. Если вывод длиннее одной строчки, а запуск команды два раза быстр и производит одинаковый текст, то в GUI это будет сложнее сделать. Отдельно про SO: у меня есть
, в Vim можно сделать привязку для того же (а можно просто выделить текст и сделать «>gv>», затем вставить). Интересно услышать, как вы копируете код из GUI.
Копирование откуда‐то ещё тривиальнее.
Grep обычно делается из Vim, а не из консоли в этом случае, так переход к найденному можно осуществить гораздо быстрее.
В Vim очень удобно использовать Command-T для открытия файлов. Впрочем, это не единственное дополнение на эту тему: есть также FuzzyFinder, Unity, ku, LustyExplorer, … А автодополнение файлов в Vim убого. Я как‐то сделал аналог автодополнения файлов в zsh (причём, в zsh автодополнение именно файлов оказалось несколько хуже), но Command-T оказался ещё удобнее, поэтому проект заглох несмотря на несколько очевидных проблем.
Относительно virtualenv: “workon env” не работает в Vim (в смысле, если запустить workon и затем Vim, встроенная поддержка python будет игнорировать виртуальное окружение, но запущенные из Vim команды игнорировать не будут). Приходится использовать github.com/jmcantrell/vim-virtualenv.
:make; посмотрите её описание на предмет, чем оно лучше:!make.hg addremove --similarity.Git не сохраняет информацию о переименованиях, он смотрит на процент сходства. То же, что я говорил, просто это поведение по‐умолчанию у некоторых команд. Mercurial, наоборот, никогда не смотрит на сходство файлов.
git help diff, там есть ключи--find-renames,--find-copies,--find-copies-harder. Если бы git сохранял информацию о переименованиях, зачем бы были нужны такие ключи?incoming/outgoing,heads,serve. Это всё подозрительно напоминает отнюдь не Git, а Mercurial.Это не значит, что всё идеально: не хватает двух вещей:
Без первого писать всё так же будет нелегко, в нынешней стадии интерфейсы отнюдь не идеальны. Поддержка Python, насколько я знаю, сделана на сейчас лучше всего (после моего патча, добавляющего pyeval()/py3eval() и vim.bindeval(), до того лучше было у lua), но моей единственной целью на момент написания было избавление от весьма прожорливой сериализации/десериализации, являвшейся единственным способом вернуть данные обратно в VimL.
Без второго будет сложно делать первое. При написании патча, к примеру, несколько static функций из eval.c перестали быть таковыми. В интерфейсе с lua они, кстати, почему‐то были просто скопированы из eval.c и уже устарели.
Идеальной реализацией второго, по моему мнению, может быть такая, при которой VimL станет таким же дополнением, как и Python. Но это работа, сопоставимая по сложности с написанием Vim с нуля.