Pull to refresh

Comments 50

Никогда не любил такие вещи. По-моему намного лучше самому наращивать функционал своего инструмента по потребностям.
Тогда зачем написали статью? Те кто любят уже пользуются python-mode, а те кто не любят использовать ваши конфиги не станут.
Ну у меня не сборка, а просто перечисление основного набора плагинов. vimrc здесь большее для того, чтобы можно было посмотреть, как это все дело настроить.
Пользовался VIMом, а сейчас использую PyCharm.
Во-первых в IDEшках есть тоже «hotkeys». Не такие широкие и полноценные, как в VIМе и EMACSе, но хватает с головой. Во-вторых в больших проектах нужно часто бегать между классами, методами. В-третьих у меня обычно получается такой один час работы: дебажусь, думаю, изучаю код 55 минут, пишу сам код — 5 минут.
Быстро подправить код — VIM.
Писать здоровезный проект — мой выбор упал на PyCharm.
Еще аргумент в пользу IDE это автодополнение методов для объектов и их подобьектов, что для вима не всегда под силу.
Для IDEA, кстати, есть достаточно функциональный VIM-плагин. Я так понимаю, он и под PyCharm заведётся.
Не знаю как по питону, но по Ruby VIM отлично бегает и дебажит.

И чего, прям и рефакторить позволяет именно методы нужного класса, а не все, которые в проекте с таким именем?

Честно говоря без понятия, вы дату публикации видели? :)
тоже перешел с vim'а на pyCharm, хотя в виме уже лет 10 точно пишу :)
скорость разработки заметно выросла.
pysmell неплохо дополняет имена переменных, классов, но по ключевым словам языка — нет.
чтобы быстрее набирать текст. Ещё у меня pysmell довольно медленно работает, если в индекс запихнуть стандартную библиотеку питона. Может я что-то упустил в его использовании? Если пользуешься pysmell, то поделись, пожалуйста, опциями индексации файлов, какие либы туда включаешь, чтобы им было удобно пользоваться.
Я вообще автокомлитом не пользуюсь. А разве omnicompletion не работает по-умолчанию со стандартной библеотекой?
omni плохо работает с объектами проекта.

зачем советовал pysmell, если не пользуешься им?
в NERDTree есть :Bookmark MyProject, потом «B» для выбора нажать достаточно. Удобно.

P.S. Тоже на F2 посадил, правда пользуюсь в рельсах )))
Круто, получается что-то вроде менеджера проектов. Спасибо.
нормального менеджера так и не нашел. делаю так. незачто. правда, про джанго не знаю (((

там еще слешом можно искать файлы\директории )))

no pasaran
Зачем имитировать работу VIM, если можно работать в VIM?
Однажды привыкнув к hjkl вы не скоро захотите возвращаться к обычным раскладкам. Хороший плагин.
Возможно тем, что кроме раскладки, людям требуются и другие возможности — такие как удобный дебаг, доступ из консоли к переменным непосредственно во время исполнения программы и т.д.
Когда-то тоже радовался NerdTREE. Потом попробовал Sublime Text 2 и захотелось такого же открытия файлов, через Cmd+P, и нашел command-t

Но в итоге пересел-таки на сублим :)
Аналогично, попробовал Sublime 2, ничего другое больше не нравится, кстати там есть и vim-mode =)
vim-mode пробовал, но не пошло. vim и st2 по отдельности отличные редакторы, но из одного лепить другой как-то не то.
Ни одна IDE не предоставляет качественной эмуляции Vim. Несколько раз пытался «слезть» с Vim, и всегда возвращался на него. А если кто-то уверяет, что эмуляции им достаточно, то скорей всего они не использовали всех возможностей этого редактора, такие люди используют только dd, перемещаются по тексту стрелками и гордо заявляют, что они — пользователи вима. Фу.

Про автодополнение: никогда не понимал тех, кто жалуется на его корявость, ведь всегда можно открыть интерпретатор, а там вам и dir() и help(); в более сложных ситуациях help() можно вызвать прям в коде. А автодополнение по открытым файлам отлично работает, и именно оно зачастую и нужно.

Про переходы по классам и файлам: обычно я знаю, в каких файлах, какие классы, и открыть их — дело пары секнд (возможно даже быстрей, чем прицелиться мышкой), а если это не так, значит проект имеет плохую структуру. Для чужих проектов есть grep. И да, всегда можно настроить индексацию проекта, и тогда переходы по классам будут работать.

Не забываем, что Vim — это редактор текста, а не IDE, но на мой взгяд его возможности с головой покрывают отсутствие каких-то «надуманных» IDE-шных удобностей.

Где-то давно слышал высказывание, что Linux сам является одной большой средой разработки, так что: Vim + консоль — наше всё :)
А каких именно возможностей VIM вам не хватает в эмуляторах типа IdeaVIM в PyCharm или поддержку vim в Komodo?
Я не могу сказать на вскидку, но как только садишься за «эмулятор» Vim, то сразу мешают какие-то мелочи: либо чего-то нет вообще, либо то, что есть, работает не так.

Хотя… кажется, вспомнил пример: когда работал в AppCode, включал режим Vim, и, насколько я помню, сочетание клавиш ci" ни к чему не приводит, хотя оно довольно часто используется. Еще, вроде бы, там не работали команды перехода к символу (t и f). Вот из таких мелочей и складывается впечатление.

Опять же не будем забывать, что Vim — это не только удобное перемещение по тексту (которое уже неправильно эмулируется), но это еще и огромная куча других инструментов: сплиты, метки, макросы, гибкая конфигурация, различные команды. Подобных вещей вообще нет в «эмуляторах». А ими пользуюсь постоянно, особенно сплитами. (и не надо говорить, что в SublimeText есть сплиты: пара заготовленных шаблонов для разделения экрана — ничто по сравнению со сплитами в Vim)
использую vim и pycharm — на проектах со сложной структурой, где требуется частая отладка и т.д. — PyCharm и его возможности мне значительно удобнее.

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

По поводу комбинаций клавиш — в pycharme есть недостатки, но они не критичны по сравнению с возможностями которые он дает.
Думаю, спорить тут не о чем. Мы приверженцы разных церквей. :)

Для меня — редактирование текста — самое критичное место, и лучше Vim с этим ничего не справится — 100%.
Странная проблема.
У меня столько времени уходит на обдумывание, что даже если бы я набивал код морзянкой, производительность не очень бы пострадала.

Гораздо важнее хорошее автодополнение, базовые возможности рефакторинга и прочие вещи, которые позволяют сокращать количество ошибок.
Это может довести и до крайности.
Один мой коллега, работая в нетбинсе, пишет код без всякого форматирования, чуть ли не в одну строчку, потом нажимает заветное сочетание клавиш для автоформатирования всего файла. И так после каждых нескольких строчек. Где тут культура программирования?

Другая проблема: доходит он до места, где тип переменной сложно определить даже человеку (например, объект возвращается из хитрой функции), и автокомплит ломается, а он — бедненький — сидит, тычит клавишу автодополнения и не знает, что дальше предпринять… Не привык он думать и разбираться.

Также фанатичное отношение к автокомплиту приводит еще к одной проблеме (и такое я частенько наблюдаю у некоторых людей): берёт программист новую библиотеку, тыкает автодополнение — «о! название класса похоже на то, что мне нужно!», создает объект, тыкает автодополнение, смотрит список функций — «о! кажется, эта функция будет выполнять то, что мне нужно!»… и т.д. В общем: складывание программы из неизвестных «кубиков» наугад, а потом долгое копание в том, почему же оно не работает так, как ожидалось, с очень неохотным включением мозгов. Так подрастает, простите за прямоту, поколение «кодеров», которые без своего любимого инструмента (да и с ним зачастую тоже) сидят и тупят, как амёбы, вместо того, чтобы изначально почитать и разобраться в проблеме.

Следите за собой, люди! Работа должна быть творческая, не бойтесь думать!
Да, это крайности.

Автокомплит мне нужен в первую очередь не для своего кода, так как стараюсь работать в рамках одной конвенции для предсказуемости всех имен, а сторонних или встроенных библиотек. Каждый раз лезть в доки и вспоминать как тут правильно будет называться метод: getFile, get_file, fileget, gfile для меня все-таки утомительно.

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

Если программируешь кубиками… ну некоторые вообще программируют сниппетами, кто сказал, что студент-вебмастер невостребованная прослойка и вообще доминирует интеграционное программирование когда количество создаваемого для проекта кода мало относительно объема 3rd-party. Тут просто нет смысла ставить вопрос о культуре и понимании.
Вы правы — главное в этом деле осознанность. Если человек знает логику работы того, что он пытается автокомплитить, и уже ожидает увидеть в предложенных вариантах что-то конкретное, то тут от комплита только польза в виде быстрого набора текста.
А изучение кода по комплиту — грех. :)
Тоесть вы приходите на новые проект, не знаете код (а его ооочень много, так как он писался больше года), и хотите доказать мне, что grepом быстрее бегать по классам, методам, искать нужные части кода и т.п.?
Если знаешь проект, то четко знаешь, что ищешь — тут да, вы правы. Но если этот проект для вас новый и очень большой, либо вы юзаете 10 либ и нужно понять, как они устроенны внутри — тут grepом можно долго мучаться.
Видимо, мне еще не приходилось переходить на подобные проекты, где я бы не смог разобраться, где и что искать. Но если и придется, вряд ли для этого я буду ставить ide. Быстрей уж проиндексировать его и в vim «бегать по классам, метода, искать нужные части кода».

Я уже упомянул, что удобство редактирования — самое важное для меня.
не подскажете, как запускать django-проекты в Sublime Text 2? :)
тоже приклядываюсь к этому редактору…
Хотелось бы сказать спасибо за Solarized Colors, не зря заглянул в топик, не смотря на то, что к питону никакого отношения не имею.

Что такое позволяет делать ВИМ, чего невозможно достичь в том же пайчарме, ради чего стоит столько времени тратить на его изучение и настройку?

Вы же видели дату публикации статьи, да?
Only those users with full accounts are able to leave comments. Log in, please.