За свою трудовую жизнь мне довелось поработать со множеством IDE — от Microsoft Visual Studio, Eclipse и NetBeans, до KDevelop, PhpStorm и RubyMine. Последние полгода я использую в работе только Vim, потому что не знаю как оттуда выйти. Сегодня, я хотел бы немного рассказать об этом инструменте, о его особенностях и преимуществах, а также развеять некоторые мифы, которые окружают этот редактор.
Данная статья не ставит целью описать все возможности Vim — на это не хватит и тысячи книг. Не будет здесь и конкретных примеров подходов и команд — справочников в сети более чем достаточно, а общий стиль работы зависит от характера пользователя и всегда уникален. Вместо этого, я попытаюсь показать, что Vim — это нечто большее, чем многие привыкли его считать; что этот инструмент вышел далеко за рамки странного консольного редактора и по своим возможностям может легко конкурировать с любым современным IDE.
Нафига оно мне?
Все IDE, что мне приходилось использовать, имеют три проблемы: скорость работы, расход ресурсов и неудобную работу с файлами на сервере. И Vim решает все три. Даже в полном обмундировании Vim позволит моментально работать с гигабайтами данных хоть на Raspberry PI. Но главное — этот редактор является частью практически любого дистрибутива Linux, а значит есть на каждом сервере. Достаточно скачать с GitHub персональные настройки и набор плагинов, и ваша IDE готова к работе. Где бы вы ни находились, создание привычной рабочей среды не займет более минуты.
Ну и самое важное: освоение Vim даст вам моральное право отпустить бороду и надеть свитер с оленями.
Возможности
У людей чья-то привязанность к Vim зачастую вызывает недоумение, ведь большинство представляет себе этот редактор как-то так:
Для многих становится откровением, что современный настроенный Vim мало чем уступает другим IDE по функциональности, а в некоторых аспектах и вовсе превосходит всех конкурентов. Вот лишь малая часть возможностей Vim, о которых вы, возможно, не знали:
К примеру, мой Vim в спокойном состоянии выглядит так:
Да, это все еще консольное окно, но согласитесь, оно ушло далеко от черного экрана на первом снимке. Еще несколько случайных картинок из Google: [1], [2], [3], [4], [5].
Идеология
В основе идеологии Vim лежат два базовых принципа:
Пользователь главнее IDE.
Современные профессиональные IDE обладают колоссальными возможностями. Редкий разработчик знает и умеет использовать хотя бы 20% от реального их потенциала. Однако, есть тут и темная сторона: IDE держит в памяти весь свой инструментарий, даже тот, который никогда не пригодится. Более того, иногда редактор решает, что лучше знает, что нужно пользователю и тогда его уже не остановить.
Вы не сможете попросить NetBeans не сканировать все файлы проекта, когда на секунду зашли поправить один файл. PhpStorm не получится заставить не выкачивать весь проект по FTP, когда все что нужно — это внести небольшую правку на удаленном сервере. А уж если ваша IDE решила, что с кодом что-то не так, готовьтесь, красные подчеркивания и всплывающие предупреждения не дадут забыть, что ваша IDE вами недовольна.
Vim использует обратный подход. После установки вы получите не более чем необычный текстовый редактор — то, что представлено на первом изображении. Все остальное за вами. Вы самостоятельно определяете, какая функциональность вам понадобится, самостоятельно находите, устанавливаете и настраиваете плагины. Вы — повелитель своей IDE. Лишь вы определяете, как, что и когда она будет делать и показывать.
С одной стороны, это серьезно затрудняет знакомство с Vim, так как плагинов существуют десятки тысяч, а настроек — без преувеличения миллионы. Потеряться в этом очень просто. С другой стороны, достаточно настроить свою IDE один раз, выложить файл с настройками на GitHub и ваша IDE доступна вам везде. Кроме того, облегчить знакомство помогут готовые сборки от других поклонников этого редактора.
Мышь мешает работе.
Золотое правило работы с Vim предполагает, что большинство пальцев в любой момент времени не покидают home row — средний ряд клавиатуры. Работа с мышью при этом, хотя и возможна технически, исключается.
Это неожиданно, но такой подход не только в несколько раз увеличивает скорость набора и редактирования кода, но и позволяет дольше "оставаться в потоке" — существенно увеличить свою продуктивность.
Особенности
Поначалу я хотел привести плюсы и минусы Vim в сравнении с другими IDE, но каждый пункт, который всплывал в голове, можно было отнести как к плюсам, так и к минусам. Потому, представлю их общим списком случайных фактов:
Vim надо сначала учиться, а затем привыкать;
Vim придется настраивать;
Vim имеет два режима: всё портить и бибикать текстовый и командный;
На вашей стороне вся палитра красок из 256 цветов;
В Vim работают все комбо из Mortal Combat, иногда с тем же результатом;
Переход к любому месту любого файла проекта можно сделать в шесть нажатий клавиш;
Мастера Vim укладываются в четыре нажатия;
Нет такой функциональности, которую нельзя реализовать в Vim;
Иногда это потребует времени и запаса напильников;
Обучение Vim не заканчивается никогда.
Вопросы и ответы
- Если я решусь попробовать, с чего начать?
Первый шаг — открыть консоль в системе, где есть Vim и набрать команду vimtutor. Спустя полчаса выполнения упражнений вы получите базовые навыки работы с редактором.
Второй шаг — загрузить с GitHub готовую сборку плагинов к Vim. Без опыта работы с Vim разобраться в его плагинах и настройках крайне трудно. Потребуется воля, время и много терпения. Готовые, настроенные пакеты позволят быстро погрузиться в среду, а приключения персональной настройки оставить на потом. В частности, я начинал свой путь с этого пакета: https://github.com/joonty/myvim.git.
Третий шаг — решать все свои задачи в Vim, когда это позволяют обстоятельства. Уже через неделю ежедневного использования Vim, работа в обычной IDE покажется такой же удобной, как программирование ногами.
- В Vim разработка замедлилась, а руководство хочет решений прямо сейчас. Как быть?
Освоение любого нового инструмента требует времени. Не является исключением и Vim — в первую неделю использования этого редактора скорость разработки может заметно снизиться. Поэтому, на первых порах можно использовать два редактора — привычную IDE для немедленных задач и Vim для всего остального.
Например, я окончательно попрощался с NetBeans лишь спустя месяц с начала использования Vim. Поначалу было тяжело, но сейчас считаю потраченные на освоение Vim силы одной из лучших инвестиций своего времени за всю трудовую жизнь.
- Я слышал байку о том как человек подсел на Vim, от него отвернулись друзья и бросила девушка. Правда ли это?
Нет, это история про Emacs.
- Почему все комбинации клавиш такие непонятные? Их невозможно запомнить!
Разработчики постарались сделать горячие клавиши как можно более логичными. Например команда g происходит от слова go, p — от paste, v — от vыделить. Если какое-то действие или сочетание запоминается особенно трудно, его всегда можно переопределить на более удобное. Опыт показывает, что за неделю ваши пальцы сами запомнят все команды.
Заключение
Этой статьей я не призываю отказаться от привычных инструментов, но хочу развеять устоявшееся менение о том, что Vim — это лишь белые буквы на черном экране.
Редкие разработчики начинают свою трудовую деятельность вместе с Vim. Кривая обучения этому редактору очень крута, а идеи в основе редктора зачастую непонятны новичкам. Как правило, люди приходят к Vim, уже имея за спиной богатый опыт использования других IDE.
Однако, те из них, кто выдерживает первый недельный шок, нередко остаются с этим редактором навсегда. Философия Vim затягивает настолько, что многие начинают распространять ее на другие инструменты — браузеры [1][2], почтовые клиенты [1], классические IDE [1][2][3].
В свое время, это заставило меня задуматься и, в конце концов, преодолеть предвзятое отношение к этому замечательному редактору. Надеюсь и некоторые из вас решатся дать ему шанс.
Анонс
Следующая статья будет называться "Забудьте о Chrome и Firefox! Консольный браузер Lynx — ваш лучший выбор".
Никак не заставлю себя использовать это повседневно, хотя наборы плагинов меня просто сразили своей функциональностью, а главное есть и красивые цветовые схемы
Статья интересная, но есть несколько спорных моментов.
Иван написал: Вы не сможете попросить NetBeans не сканировать все файлы проекта, когда на секунду зашли поправить один файл
Могу, при открытии NetBeans у меня в нижней части окна появляется прогресс бар сканирования файлов, с права крестик для остановки сканирования.
Иван написал: PhpStorm не получится заставить не выкачивать весь проект по FTP, когда все что нужно — это внести небольшую правку на удаленном сервере
Не знаю о какой версии речь, но в последней версии можно выкачать один нужный файл.
Иван написал: Где бы вы ни находились, создание привычной рабочей среды не займет более минуты.
Уже придираюсь, но один только gvim74.exe скачивается с оф. сайта с нормальным интернетом дольше минуты. Так что минут 5 или 10 звучало бы убедительнее
Скачал gvim74.exe, поставил. Что делать дальше и как работать с современным PHP сходу и не понятно
Спасибо, довольно любопытно выглядит, прокачаю свой вим.
Иван, несколько вопросов: 1. Насколько глубоко проработан функционал рефакторинга? Переименование методов / классов / нэйм-спейсов в рамках всего проекта? 2. Возможна ли интеграция с трекерами задач и сохранение различных состояний проекта в связке с тикетами из трекера? 3. Сохранение и использование снипетов кода и заготовок файлов в рамках множества проектов?
Постоев Олег написал: Могу, при открытии NetBeans у меня в нижней части окна появляется прогресс бар сканирования файлов, с права крестик для остановки сканирования.
К сожалению, в случае со сканированием этот крестик является декоративным, о чем NetBeans радостно сообщает при попытке на него нажать:
Единственный действенный способ заставить NetBeans не сканировать файлы постоянно — это установить плагин ScanOnDemand. Однако, интегрировать его можно не с любой версией IDE (с последней — 8.0.2 пока не выходит). Кроме того, работа плагина имеет побочные эффекты — в большинстве случаев переход к определению функции и подсказки перестают нормально функционировать, что превращает NetBeans из современной IDE в обычный тяжелый текстовый редактор.
Я проработал с NetBeans без малого четыре года, много общался с его с разработчиками, очень уважаю этот проект и до сих пор слежу за его развитием. Тем не менее, у этой IDE есть ряд особенностей, которые делают его малопригодным для разработки проектов удаленно. Сканирование файлов — не самая большая беда. С недавних пор появилось гораздо более неприятная особенность — при открытии проекта NetBeans сканирует все файлы проекта на предмет чего-то, связанного с HTML5. Приступить к редактированию файлов до завершения этого процесса невозможно, как невозможно и отказаться от него.
В итоге, даже локальный проект на Битрикс может открываться до десяти минут, парализуя на это время работу. Открытие же примонтированного проекта и вовсе может занять несколько часов. К несчастью, это не временная ошибка, но путь, который избрали разработчики NetBeans — эта IDE только для локальной разработки.
Постоев Олег написал: Не знаю о какой версии речь, но в последней версии можно выкачать один нужный файл.
Охотно верю. PhpStorm бесспорно является лучшей IDE для PHP (после Vim). Была бы она еще и бесплатной...
Постоев Олег написал: Уже придираюсь, но один только gvim74.exe скачивается с оф. сайта с нормальным интернетом дольше минуты. Так что минут 5 или 10 звучало бы убедительнее
Речь шла о скачивании не Vim, а обвеса к нему — заранее подготовленных настроек, размещенных, например, на GitHub, которые делают из простого редактора полноценную IDE. Организовать себе привычную среду в этом случае можно удаленно — на сервере разработки или даже на продуктивном сервере. При этом, установка будет заключаться в выполнении команды git clone, а локальные ресурсы в последующей работе не будут задействованы совсем.
Постоев Олег написал: Скачал gvim74.exe, поставил. Что делать дальше и как работать с современным PHP сходу и не понятно
Даже из коробки Vim показывает свое превосходство! Какая еще IDE может похвастаться подсветкой специально для PHP 2?
А если серьезно, установка Vim — это лишь малый шаг к началу полноценной работы с редактором. Подробности этого описаны в первом пункте раздела "Идеология". Также рекомендую обратить внимание на вопрос "С чего начать".
Добавлю, что по моему мнению приступать к освоению Vim стоит лишь после плотного знакомства с Linux. Vim — это редактор, который во всем следует философии Unix. И по-настоящему оценить его можно только поняв и приняв эту философию. Пользователь, привыкший к окнам и контекстным меню Windows, вряд ли найдет Vim удобным подходящим для работы.
Самохвалов Никита написал: 1. Насколько глубоко проработан функционал рефакторинга? Переименование методов / классов / нэйм-спейсов в рамках всего проекта?
Во-первых, стоит отметить, что Vim — это прежде всего редактор. Такое понятие как проект в терминах других IDE, в контексте работы с Vim просто отсутствует. Далее под проектом я буду подразумевать некоторую папку в которой размещены подкаталоги и файлы проекта.
Также стоит заметить, что как таковой Vim предоставляет лишь функциональность редактора и не более того. Все остальные его возможности инкапсулированы в плагины, которые разрабатываются сообществом и отдельными энтузиастами. Число таких плагинов на данный момент превышает десять тысяч, некоторые из них дублируют или дополняют функциональность друг друга.
Поэтому, ответить на вопрос о проработанности какой-то функциональности крайне сложно. Есть плагины, которые лучше умеют одно, но хуже другое. И наоборот. Причем иногда, проще написать свой плагин, чем найти или заставить работать как хочется чужой. Благо, помимо собственного языка Vim позволяет использовать для этого Python. Важно понимать, что Vim — это скорее конструктор, нежели законченный продукт.
Что касается рефакторинга, то в настоящий момент ведется разработка нескольких перспективных плагинов и некоторые из них уже показывают довольно интересные результаты. Тем не менее, до уровня PhpStorm Vim в этом плане еще очень далеко. Переименование классов, методов и namespace я бы делал с помощью массового поиска и замены с подтверждением по всем файлам проекта. Не так круто, как рефакторинг, но быстро, действенно и решается одной командой.
Самохвалов Никита написал: 2. Возможна ли интеграция с трекерами задач и сохранение различных состояний проекта в связке с тикетами из трекера?
Существуют плагины обмена с Redmine и Jira, которые позволяют просматривать и обновлять задачи прямо в Vim, а также как-то задействовать Git. Если честно, я с ними пока не работал. Возможно, смог бы ответить точнее, если бы понимал как это должно работать.
Самохвалов Никита написал: 3. Сохранение и использование снипетов кода и заготовок файлов в рамках множества проектов?
Вот это есть на любой вкус в десятках вариантов, в том числе самых немыслимых.
Иван написал: В итоге, даже локальный проект на Битрикс может открываться до десяти минут, парализуя на это время работу. Открытие же примонтированного проекта и вовсе может занять несколько часов. К несчастью, это не временная ошибка, но путь, который избрали разработчики NetBeans — эта IDE только для локальной разработки.
Не обязательно выкачивать все директории битрикса, можно вообще папку bitrix не выгружать - тогда не будет сканироваться. У меня даже на слабом ноутбуке с несколькими десятками проектов на битриксе NetBeans дольше 1 минуты никогда не запускался. На нормально компьютере 20-40 секунд.
Иван написал: Даже из коробки Vim показывает свое превосходство! Какая еще IDE может похвастаться подсветкой специально для PHP 2?
Ценю ваш тонкий юмор Может быть заодно поделились бы своей конфигурацией?
Иван написал: Пользователь, привыкший к окнам и контекстным меню Windows, вряд ли найдет Vim удобным подходящим для работы.
Если Vim действительно может увеличить продуктивность и эффективность работы - было бы интересно изучить его... но только в Windows
Иван , подскажите, а как вы работаете с проектами, которые располагаются на хостинге с доступом по FTP? Не смог найти нормального метода работы кроме того, как каждый раз вбивать адрес, логин и пароль для ftp. В идеале хотелось бы видеть какой-то список проектов/подключений, выбрав из списка элемент - подключаемся к этому хосту и можем ходить по файловой структуре и редактировать файлы.
Чучадеев Николай написал: Иван , подскажите, а как вы работаете с проектами, которые располагаются на хостинге с доступом по FTP? Не смог найти нормального метода работы кроме того, как каждый раз вбивать адрес, логин и пароль для ftp. В идеале хотелось бы видеть какой-то список проектов/подключений, выбрав из списка элемент - подключаемся к этому хосту и можем ходить по файловой структуре и редактировать файлы.
Тут есть несколько подходов:
1. Самый правильный — использовать Unix-way, главный принцип которого — каждый инструмент должен решать свою задачу и делать это хорошо.
Vim — это в первую очередь редактор, и его главное назначение — редактировать файлы. Предоставление же доступа к файлам должно лежать в компетенции файловых сиситем, как локальных (FAT32, NTFS, ext4), так и сетевых (CurlFtpFS, SSHFS, NFS).
Таким образом, лучшим подходом к работе с удаленным ресурсом является монтирование (подключение сетевого раздела). Так, Windows из коробки умеет подключать FTP и NFS диски. Для монтирования же SFTP ресурсов существует множество бесплатных программ. В Linux для FTP можно использовать CurlFtpFS, для SSH — SSHFS и так далее. После монтирования, удаленные файлы станут доступными, как если бы они были локальными, и Vim сможет работать с ними, не заботясь о вопросах сетевого обмена.
Еще одним плюсом такого подхода является тот факт, что работа с файлами более не ограничивается предустановленными в IDE протоколами. Монтирование можно производить по любому доступному протоколу, например HTTP (WebDAV) или cifs.
2. Другим предпочтительным вариантом является использование локальной копии Vim.
Редкий современный хостинг не предоставляет доступ по SSH. И любой современный Linux имеет в своем комплекте Vim. Достаточно загрузить на удаленный сервер папку .vim со своими настройками и плагинами, и разницы между локальным и удаленным Vim не будет никакой. Также этот способ позволит сэкономить ресурсы системы.
3. Если по каким-то причинам первые два варианта не подходят, можно воспользоваться подходом других популярных IDE. Этот подход заключается в полной загрузке файлов проекта, с последующей синхронизацией изменений. Загрузку можно выполнить, например, с помощью rsync, а с задачей синхронизации неплохо справляется плагин vim-sync.
Иван , при использовании Vim по SSH каким образом вы копируете текст в системный буфер? Судя по тому что удалось найти -это либо не возможно либо куча граблей.
Чучадеев Николай написал: Иван , при использовании Vim по SSH каким образом вы копируете текст в системный буфер? Судя по тому что удалось найти -это либо не возможно либо куча граблей.
В общем случае, работа с системным буфером осуществляется через регистры * и +. Однако, как я понял, в данном конкретном случае речь идет о подключении с использованием PuTTY. Тут, действительно, скопировать что-либо в буфер операционной системы получится лишь с использованием мыши и только в пределах экрана. К сожалению, это ограничение PuTTY и затрагивает оно все консольные программы, не только Vim.
В данной ситуации я бы порекомендовал обратить внимание на идею с монтированием папки по SSH. Другие варианты: пропатчить PuTTY (готовые патчи есть, но их применение потребует некоторых навыков программирования и сборки программ под Windows), или попытаться подыскать другой SSH клиент (к сожалению, не смогу ничего посоветовать, так как уже долгое время не работал с Windows).
Чучадеев Николай написал: Иван , забыл написать - я под linux'ом. Вы эту проблему под linux'ом как-то обходите? Или вы под MacOS?
И ведь действительно не работает! Кто бы мог подумать. С другой стороны, это показывает что эта функция мне нужна не так и часто. Когда требуется что-то скопировать, обычно использую мышь.
И поиск по интернету действительно показал, что простых решений нет. Тем не менее, пользователям Linux не пристало сдаваться. Мой извращенный вариант обхода проблемы:
1. Установить на локальной машине netcat (nc), netstat и xclip. Думаю, это не станет проблемой. Тем более, что с высокой долей вероятности они уже установлены.
2. Дописать в .bashrc в домашней папке пользователя на локальной машине вот такую функцию:
Для подключения к удаленному серверу использовать команду vimful-ssh вместо привычного ssh. Копирование настроено на старый добрый Ctrl+c. Буфер доступен по средней кнопке мыши.
Решение выдумывалось впопыхах, потому гарантировать полное отсутствие проблем не могу. Однако, проверил на двух разных системах, вроде все работает.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».