Настраиваем Vim для работы с Python кодом

[jmistx]

Спасибо за статью.
Я не так давно использую vim для написания питонового кода, и, наверное, многие вопросы до сих пор «детские».

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

P.S. У вас rope autocomplete не притормаживает?

[ali_aliev]

Тесты через консоль, как и всегда. Отладка, если необходима, то через pdb (кстати, посмотрите еще PuDB). По поводу табов и буферов поищите в Интернете документации много на эту тему, переключаюсь между буферами через Command-T. Если нужна навигация по коду попробуйте расширение Taglist, для создание файлов и директорий, а так же просмотра текущего каталога использую NERDTree. По поводу притормаживания Rope autocomplete почитайте тут, но автокомплитом пользуюсь редко.

[icc]

Я бы еще порекомендовал расцветку slate: colorscheme slate.
Лично у меня от нее почти не устают глаза.

[JIghtuse]

solarized — отличная схема. Существует как vundle plugin: github.com/altercation/vim-colors-solarized

В целом хорошая статья. Тоже использую vundle и схожие хоткеи с запятой в качестве leader (многие брал с vimcasts).
Отрывок с gui_options вызвал некоторое недоумение. Для объяснения удобен, но можно ведь короче:

gui_options

if has('gui_running')
  set guioptions=e
  set background=light
endif

[erthalion]

Для powerline есть некоторое количество легких аналогов. Например, мне больше по душе lightline.vim

[VanSanblch]

Продолжая тему замены statusline в vim'е — перешёл на vim-airline него после того как Lokaltog/vim-powerline стал deprecated.

Плюс у автора vim-airline отличный vimrc из которого можно почерпнуть массу полезных настроек.

[ali_aliev]

Спасибо. Не знал что powerline устарел

[VanSanblch]

Автор просто полностью переписал его на питон и отказался от поддержки прежней версии. Актуальную можно взять от сюда — github.com/Lokaltog/powerline

[xaizek]

Спасибо за статью, в целом интересно, но хотелось бы указать на несколько мелочей.

не собираюсь делать из Vim «комбайн», напичкав его огромным количеством плагинов

Кажется, у Вас это не слишком хорошо получилось, в первую очередь из-за Python-mode, который по сутя является объединением функциональности целой кучи плагинов.

nmap <leader>l :set list!<CR>

Тут и в принципе лучше писать:
nnoremap <leader>l :set list!<cr>
И менять на nmap только где это необходимо.

добавьте в vimrc строку set paste

Не делайте так! 'paste' делает нерабочими практически все маппинги в режиме вставки и не должен использоваться таким образом, лучше pastetoggle выставить.

set nocompatible

Несколько утомило уже это видеть в каждой статье про настройку Vim, в документации к 'compatible' ведь написано:

When a vimrc or gvimrc file is found while Vim is starting up, this option is switched off

[ali_aliev]

Спасибо за ваш комментарий. set nocompatible требует расширение vundle, в документации написано что необходимо установить данную опцию. По поводу python-mode согласен

[xaizek]

Так Vim сам сбросит эту опцию, если файл конфигурации называется .vimrc а не .exrc. Т.е. явно сбрасывать её нет необходимости, так как к моменту исполнения той строчки опция уже сброшена.

[ZyXI]

Ага. А если вам по каким‐либо причинам надо использовать vim -u /path/to/.vimrc (например, хотите запустить vim с вашим vimrc на чужой машине или избежать использования системного /etc/vim/vimrc//etc/vimrc (зависит от дистрибутива)), то никакое название файла вам не поможет: с -u Vim запускается в режиме совместимости, если нет -N (про который легко забыть). Так что лучше воспользоваться замечательным принципом Python «явное лучше скрытого» и не говорить о ненужности.

[xaizek]

Да, посмотрел описание ключа -u и там это явно написано. Я думаю, что кто его часто используют должны это знать и учитывать, а не надеяться на то, что где-то будет уже всё предусмотрено. Не уверен, что в данном случае «явное лучше скрытого» надо применять к файлу конфигурации, а не к параметрам. Хотя согласен, что здесь это может быть проще и удобнее.

[ZyXI]

set nocompatible — это и есть учёт. «Не надеяться на то, что где‐то будет уже всё предусмотрено» для собственного файла настроек имеет не больше смысла, чем засовывать весь vimrc в аргументы командной строки. Чем строчка set nocompatible так принципиально отличается от inoremap ,a <C-o>A, что на присутствие второй я надеяться могу, а на присутствие первой — нет?

[xaizek]

Да я в целом согласен, что корректнее настраивать файл настроек в нём же. Но меня никак не покидает чувство «костыльности» данного решения, так как на практике в 99% запусков, эта строчка не нужна, а вот сочетания нужны всегда. А пользователи читают везде, что нужна, и потом думают, что она прямо таки жизненно необходима. Не знаю, может меня теребит именно эта неосведомлённость.

[ZyXI]

Я считаю костыльной неочевидную логику, когда set nocompatible в начале vimrc эквивалентно наличию .vimrc с определённым именем файла в определённом месте, загружаемого определённым образом (точнее, одним из двух определённых способов: по‐умолчанию и с $VIMINIT; во втором случае имя не важно). Это слишком много условий, для того, чтобы на них можно было положиться. И слишком много возможных причин их нарушить (хотя, конечно, нарушение не происходит в большинстве случаев).

Если быть точным: я бы не стал внедрять такую логику вообще, если бы писал Vim.

[khart]

Вместо Command-T можно использовать CtrlP.
Этот плагин удобнее, потому что он ищет не только в файлах, но и в буферах, поддерживает регулярные выражения и так далее.
Очень функциональный плагин.

[nwalker]

И, что тоже плюс, не требует Ruby.

[ZyXI]

Command-T тоже ищет в буферах. Точнее, он ищет либо там, либо там.

Command-T плох тем, что в issues уже весьма давно лежит патч, позволяющий расширять Command-T (т.е. использовать свою функцию создания списка), но никаких средств расширения нет до сих пор. В CtrlP они есть, причём с неплохим API. Когда мне надо было написать расширение для Command-T пришлось делать так: унаследоваться от главного класса, перед показом списка заменить глобальную переменную на экземпляр наследника, после показа вернуть всё как было. Вероятно, можно было изменить исходный экземпляр (хранится в $command_t), но я категорически не люблю monkey patching.

Command-T имеет часть, написаную на C, прослойку на VimL и большое количество кода на Ruby. CtrlP — полностью VimL, а потому работает медленнее.

Command-T не поддерживает не‐ASCII. Не знаю, как у CtrlP, но со стороны авторов Command-T можно было поддержать Unicode простым проходом по всему списку и созданием привязки для каждого нового найденного там символа.

Вообще, если бы мне не пришлось просмотреть исходный код обоих, я бы, наверное, использовал CtrlP. Но ужас с кучей глобальных переменных, сокращёнными до нельзя именами команд, принудительной установкой в modeline неудобных мне опций и, возможно, чем‐то ещё (смотрел давно) не выглядит как дополнение, которое может быть хорошим.