Comments 19
Спасибо за статью.
Я не так давно использую vim для написания питонового кода, и, наверное, многие вопросы до сих пор «детские».
Но было бы интересно посмотреть на полный воркфлоу вашей работы с питоновым проектом.
С чего начинаете, как отлаживаете, как гоняете тесты.
Как работаете с буферами и табами.
Как происходит навигация по коду.
Сложно сформулировать все вопросы из-за недостатка опыта.
P.S. У вас rope autocomplete не притормаживает?
Я не так давно использую vim для написания питонового кода, и, наверное, многие вопросы до сих пор «детские».
Но было бы интересно посмотреть на полный воркфлоу вашей работы с питоновым проектом.
С чего начинаете, как отлаживаете, как гоняете тесты.
Как работаете с буферами и табами.
Как происходит навигация по коду.
Сложно сформулировать все вопросы из-за недостатка опыта.
P.S. У вас rope autocomplete не притормаживает?
Тесты через консоль, как и всегда. Отладка, если необходима, то через pdb (кстати, посмотрите еще PuDB). По поводу табов и буферов поищите в Интернете документации много на эту тему, переключаюсь между буферами через Command-T. Если нужна навигация по коду попробуйте расширение Taglist, для создание файлов и директорий, а так же просмотра текущего каталога использую NERDTree. По поводу притормаживания Rope autocomplete почитайте тут, но автокомплитом пользуюсь редко.
Я бы еще порекомендовал расцветку slate:
Лично у меня от нее почти не устают глаза.
colorscheme slate.Лично у меня от нее почти не устают глаза.
solarized — отличная схема. Существует как vundle plugin: github.com/altercation/vim-colors-solarized
В целом хорошая статья. Тоже использую vundle и схожие хоткеи с запятой в качестве leader (многие брал с vimcasts).
Отрывок с gui_options вызвал некоторое недоумение. Для объяснения удобен, но можно ведь короче:
В целом хорошая статья. Тоже использую vundle и схожие хоткеи с запятой в качестве leader (многие брал с vimcasts).
Отрывок с gui_options вызвал некоторое недоумение. Для объяснения удобен, но можно ведь короче:
gui_options
if has('gui_running')
set guioptions=e
set background=light
endif
Для powerline есть некоторое количество легких аналогов. Например, мне больше по душе lightline.vim
Продолжая тему замены statusline в vim'е — перешёл на vim-airline него после того как Lokaltog/vim-powerline стал deprecated.
Плюс у автора vim-airline отличный vimrc из которого можно почерпнуть массу полезных настроек.
Плюс у автора vim-airline отличный vimrc из которого можно почерпнуть массу полезных настроек.
Спасибо. Не знал что powerline устарел
Автор просто полностью переписал его на питон и отказался от поддержки прежней версии. Актуальную можно взять от сюда — github.com/Lokaltog/powerline
Спасибо за статью, в целом интересно, но хотелось бы указать на несколько мелочей.
И менять на nmap только где это необходимо.
не собираюсь делать из 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
Спасибо за ваш комментарий. set nocompatible требует расширение vundle, в документации написано что необходимо установить данную опцию. По поводу python-mode согласен
Так Vim сам сбросит эту опцию, если файл конфигурации называется .vimrc а не .exrc. Т.е. явно сбрасывать её нет необходимости, так как к моменту исполнения той строчки опция уже сброшена.
Ага. А если вам по каким‐либо причинам надо использовать
vim -u /path/to/.vimrc (например, хотите запустить vim с вашим vimrc на чужой машине или избежать использования системного /etc/vim/vimrc//etc/vimrc (зависит от дистрибутива)), то никакое название файла вам не поможет: с -u Vim запускается в режиме совместимости, если нет -N (про который легко забыть). Так что лучше воспользоваться замечательным принципом Python «явное лучше скрытого» и не говорить о ненужности.Да, посмотрел описание ключа -u и там это явно написано. Я думаю, что кто его часто используют должны это знать и учитывать, а не надеяться на то, что где-то будет уже всё предусмотрено. Не уверен, что в данном случае «явное лучше скрытого» надо применять к файлу конфигурации, а не к параметрам. Хотя согласен, что здесь это может быть проще и удобнее.
set nocompatible — это и есть учёт. «Не надеяться на то, что где‐то будет уже всё предусмотрено» для собственного файла настроек имеет не больше смысла, чем засовывать весь vimrc в аргументы командной строки. Чем строчка set nocompatible так принципиально отличается от inoremap ,a <C-o>A, что на присутствие второй я надеяться могу, а на присутствие первой — нет?Да я в целом согласен, что корректнее настраивать файл настроек в нём же. Но меня никак не покидает чувство «костыльности» данного решения, так как на практике в 99% запусков, эта строчка не нужна, а вот сочетания нужны всегда. А пользователи читают везде, что нужна, и потом думают, что она прямо таки жизненно необходима. Не знаю, может меня теребит именно эта неосведомлённость.
Я считаю костыльной неочевидную логику, когда
Если быть точным: я бы не стал внедрять такую логику вообще, если бы писал Vim.
set nocompatible в начале vimrc эквивалентно наличию .vimrc с определённым именем файла в определённом месте, загружаемого определённым образом (точнее, одним из двух определённых способов: по‐умолчанию и с $VIMINIT; во втором случае имя не важно). Это слишком много условий, для того, чтобы на них можно было положиться. И слишком много возможных причин их нарушить (хотя, конечно, нарушение не происходит в большинстве случаев).Если быть точным: я бы не стал внедрять такую логику вообще, если бы писал Vim.
Вместо Command-T можно использовать CtrlP.
Этот плагин удобнее, потому что он ищет не только в файлах, но и в буферах, поддерживает регулярные выражения и так далее.
Очень функциональный плагин.
Этот плагин удобнее, потому что он ищет не только в файлах, но и в буферах, поддерживает регулярные выражения и так далее.
Очень функциональный плагин.
И, что тоже плюс, не требует Ruby.
Command-T тоже ищет в буферах. Точнее, он ищет либо там, либо там.
Command-T плох тем, что в issues уже весьма давно лежит патч, позволяющий расширять Command-T (т.е. использовать свою функцию создания списка), но никаких средств расширения нет до сих пор. В CtrlP они есть, причём с неплохим API. Когда мне надо было написать расширение для Command-T пришлось делать так: унаследоваться от главного класса, перед показом списка заменить глобальную переменную на экземпляр наследника, после показа вернуть всё как было. Вероятно, можно было изменить исходный экземпляр (хранится в
Command-T имеет часть, написаную на C, прослойку на VimL и большое количество кода на Ruby. CtrlP — полностью VimL, а потому работает медленнее.
Command-T не поддерживает не‐ASCII. Не знаю, как у CtrlP, но со стороны авторов Command-T можно было поддержать Unicode простым проходом по всему списку и созданием привязки для каждого нового найденного там символа.
Вообще, если бы мне не пришлось просмотреть исходный код обоих, я бы, наверное, использовал CtrlP. Но ужас с кучей глобальных переменных, сокращёнными до нельзя именами команд, принудительной установкой в modeline неудобных мне опций и, возможно, чем‐то ещё (смотрел давно) не выглядит как дополнение, которое может быть хорошим.
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 неудобных мне опций и, возможно, чем‐то ещё (смотрел давно) не выглядит как дополнение, которое может быть хорошим.
Sign up to leave a comment.
Настраиваем Vim для работы с Python кодом