Оглавление

1. Введение (vim_lib)
2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
3. Уровень проекта и файловая система (vim_prj, nerdtree)
4. Snippets и шаблоны файлов (UltiSnips, vim_template)
5. Компиляция и выполнение чего угодно (vim-quickrun)
6. Работа с Git (vim_git)
7. Деплой (vim_deploy)
8. Тестирование с помощью xUnit (vim_unittest)
9. Библиотека, на которой все держится (vim_lib)
10. Другие полезные плагины

Как можно назвать редактор удобным, если он не умеет запускать то, что мы программируем? Особенностью описываемого мной в данной статье плагина, является возможность запуска чего угодно, будь то программный код, plantUML, LaTeX, Less и всего, что можно написать и запустить. Плагин vim-quickrun может показаться довольно запутанным и сложным, не смотря на прекрасную документацию, потому я решил коротко осветить его в этой статье, дабы вы могли быстрее начать им пользоваться.

Оглавление

1. Введение (vim_lib)
2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
3. Уровень проекта и файловая система (vim_prj, nerdtree)
4. Snippets и шаблоны файлов (UltiSnips, vim_template)
5. Компиляция и выполнение чего угодно (vim-quickrun)
6. Работа с Git (vim_git)
7. Деплой (vim_deploy)
8. Тестирование с помощью xUnit (vim_unittest)
9. Библиотека, на которой все держится (vim_lib)
10. Другие полезные плагины

Стоит ли рассказывать вам, как повторное использование кода и проектных решений облегчает жизнь программиста? Но все ли мы можем использовать повторно? Очень часто я сталкиваюсь в моих проектах с задачами, которые требуют копи-пасты кода и избежать этого невозможно. К категории этого «повторяемого» кода относятся все структуры используемого ЯП, многие классы проекта и тест-кейсы. К счастью давно изобретено решение, позволяющее работать с таким кодом быстрее и качественнее.

Оглавление

1. Введение (vim_lib)
2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
3. Уровень проекта и файловая система (vim_prj, nerdtree)
4. Snippets и шаблоны файлов (UltiSnips, vim_template)
5. Компиляция и выполнение чего угодно (vim-quickrun)
6. Работа с Git (vim_git)
7. Деплой (vim_deploy)
8. Тестирование с помощью xUnit (vim_unittest)
9. Библиотека, на которой все держится (vim_lib)
10. Другие полезные плагины

Проекты, это то, чего очень не хватает редактору Vim. Реализация проекта позволяет не только выделить его как отдельную сущность среди других папок и файлов в ФС, но и реализовать такие свистелки, как:

• Автоматическое сохранение и восстановление последней сессии проекта так, что после повторного открытия, мы получим редактируемый в прошлый раз файл(ы), с теми же настройками и положением
• Хранение информации о проекте, такой как автор проекта, лицензия, версия и так далее. Все эти данные можно будет добавлять в шаблоны и сниппеты
• Корневой каталог проекта строго определен. Это упростит использования других инструментов, на пример xUnit, дебагеры, генераторы документации и т.д.
• Отдельный, принадлежащий только проекту каталог .vim и файл .vimrc, аналогичный пользовательским версиям. Теперь настройки и плагины проекта будут хранится в нем

Оглавление

1. Введение (vim_lib)
2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
3. Уровень проекта и файловая система (vim_prj, nerdtree)
4. Snippets и шаблоны файлов (UltiSnips, vim_template)
5. Компиляция и выполнение чего угодно (vim-quickrun)
6. Работа с Git (vim_git)
7. Деплой (vim_deploy)
8. Тестирование с помощью xUnit (vim_unittest)
9. Библиотека, на которой все держится (vim_lib)
10. Другие полезные плагины

Я пользовался, наверно, всеми популярными менеджерами плагинов для Vim и у меня не было ни малейшего желания писать свой собственный, так как эти меня вполне устраивали, но было небольшое но, о котором я расскажу в этой статье.

Привет, хабраюзер!

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

В этой серии статей я решил поделиться собственными наработками и, возможно, показать, на что может быть способен этот редактор в руках программиста. Серия будет состоять из следующих частей:

1. Введение (vim_lib)
2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
3. Уровень проекта и файловая система (vim_prj, nerdtree)
4. Snippets и шаблоны файлов (UltiSnips, vim_template)
5. Компиляция и выполнение чего угодно (vim-quickrun)
6. Работа с Git (vim_git)
7. Деплой (vim_deploy)
8. Тестирование с помощью xUnit (vim_unittest)
9. Библиотека, на которой все держится (vim_lib)
10. Другие полезные плагины

Хочется сразу заметить, что я не преследую цель «посадить как можно больше людей на иглу Vim», так как статья больше расчитана на опытных пользователей, нежели на новичков.

Читатель мог бы подумать, что это очередная статья о проверке еще одного проекта из мира свободного ПО, но на самом деле, статья не столько о проверке, сколько о практике использования анализатора PVS-Studio в полностью GNU/Linux окружении. Не случайно выбором проекта для проверки стал Vim, ибо и он в этом деле сослужил свою службу.

Для начала немного о Vim

Vim (http://vim.org) — кроссплатформенный свободный текстовый редактор c 30-летней историей, являющийся наследником редактора vi и пришедший из мира Unix систем.

Vim весьма широко применяется в администрировании и разработке, во многих дистрибутивах GNU/Linux он является редактором по умолчанию. От других текстовых редакторов Vim отличается ориентацией на использование исключительно клавиатуры, текстовый интерфейс, богатыми возможностями расширения через систему написанных на Vim Script плагинов.

Для Vim существует несколько менеджеров плагинов. Я хочу рассказать еще об одном.

Введение

На Хабре уже были обзоры менеджеров плагинов: раз, два. Рассмотрим еще один: VIM-PLUG. Данный менеджер обладает рядом интересных возможностей:

• Простота установки (код плагина содержится в единственном файле)
• Быстрые установка и обновление плагинов (если Vim собран с опцией +ruby)
• Поддержка ветвей и тегов
• Постобработка

В статье автор рассказывает о причинах, побудивших его написать еще один плагин. А в это статье приводит сравнение производительности плагинов.

В какой-то степени эта статья ответ — или, скорее, дополнение — к публикации «Зачем vi-топор программисту 21-го века». Я увидел, что в комментариях люди по-прежнему удивлялись: какой смысл в этих редакторах, когда есть полноценные IDE; статья приводила немного реальных примеров и, понимая, что мне есть, что сказать, я решил поделиться собственным опытом. Написано в художественном стиле, так как думаю, если бы люди хотели сухую выжимку, они бы просто пошли читать мануалы. Так же предупрежу, что в мануалах по Емаксу клавиша «Alt» упоминается как «Meta». Я буду говорить «Alt», так как для многих это название привычней.

Не помню, когда и при каких именно обстоятельствах, но как-то очень давно я открыл для себя Git. Поначалу я не совсем, конечно, понял его преимуществ перед другими системами контроля версий, но уже порядком к тому времени подустав от TFS, которую на тот момент мы использовали в компании, решил его попробовать.

Git очень быстро завоевал мою любовь и с тех пор я даже не представляю себе свою работу без него.

Однажды, играясь и пробуя разные команды, я случайно запустил режим редактора, а Git, как оказалось, по умолчанию использовал Vim, который я до того времени в глаза и не видел. Ну и как обычно происходит первое знакомство с этим редактором? Правильно — с недоумением и перезагрузкой терминала. Банально — выйти из редактора я так и не смог и честно, даже подумал, что редактор тупо глючит. Я даже помню, как-то удивился — как же блин так получилось, что такие умные чуваки, создавшие такую мощную штуку, как Git, могли выбрать такой архаичный, тупой, непонятный и некрасивый (как мне поначалу показалось) редактор?

I've been using Vim for about 2 years now, mostly because I can't figure out how to exit it.

— I Am Devloper (@iamdevloper) 17 февраля 2014

Компания, где я работаю, разрабатывает программное обеспечение на C++ под Linux. Долгое время мы использовали Qt Creator, с редкими ребятами работающими из Emacs и Vim. Когда я сам попытался пересесть на Vim, я понял, что ситуация с плагинами для разработки на С++ очень не простая. Поработав немного с CTags, я быстро понял, что без напильника работать в Vim будет очень сложно.
К сожалению, с ростом опыта работы с Vim редактор в Qt Creator в режиме эмуляции устраивал меня все меньше, и в какой-то момент я решил потратить немного времени и разобраться, как же сделать из Vim нормальную среду.
Я очертил для себя четыре вещи, которые я бы хотел от среды разработки, и которых мне бы хватило в Vim, чтобы полностью на него перейти:

1. Автодополнение
2. Навигация по коду
3. Отладка прямо из среды
4. Интеграция с Git (в частности Blame прямо в редакторе, и Git Grep)

Автодополнение в Vim — это решенная проблема, и название у решения YouCompleteMe. Это очень качественный плагин, который реализует автодополнение для большого количества языков программирования, в частности Python и C++. Ходят слухи, что внутри Google YouCompleteMe решает и вторую проблему с навигацией кода, но использует для этого внутренные инструменты гугла для индексирования.

Интеграция с Git в какой-то степени решена с помощью vim-fugitive. Это не такая комплексная интеграция, как бывает у Jet Brains, или в Visual Studio, но сравнимая с тем, что предлагает Qt Creator. Те два сценария, которые нужны были мне: blame и grep — работают хорошо.

Отладка и навигация были проблемами, решенными гораздо хуже. В этой статье я расскажу о плагине, который мы написали для навигации по С++ коду. В конце статьи я также расскажу о том, как мы для себя решили проблему с интегрированным отладчиком.

Зачем это нужно

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

• Пробелы или табуляция
• Длина строки

Несоблюдение приведенных выше параметров стиля разными людьми в пределах одного файла ведет с следующим проблемам:

• Изрезанность кода
• Необходимость горизонтального скроллинга

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



Чтобы сразу при открытии файла видеть подобные проблемы, я написал небольшой плагин.

Вступление

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

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

Это ответ на отличную статью от Pascal Bourguignon, в которой он рассказывает о том, как запустить Emacs с PID 1.

Как мы все знаем, никто не использует Emacs.

Предложение выше как бы намекает, что это начало очередной священной войны. Пожалуйста, начинайте. Если вам хочется что-то мне сообщить, все мои контакты у меня в блоге.

На самом деле, шутки в сторону. Я считаю, что это отличная статья, и после прочтения мне захотелось посмотреть, смогу ли я сделать что-то похожее с Vim. Не в пользовательском режиме Linux, но в действительности создав ISO для загрузки. Можно сказать, «загрузиться в Vim», если вам так хочется.

Эта публикация рассказывает о том, как экономить время при разработке для Clojure и NodeJS, а также Bash скриптов, посылая текст из vim в REPL, c использованием tmux + vim + vim-slime. Также приводятся рецепты с nodemon.

Скорее всего, vim-slime сработает и для других интерпретируемых языков (Ruby / Python / PHP / Perl ...). vim-slime также работает со screen.
На хабре достаточно освещались и vim, и tmux. Я только хотел показать, что можно получить от их комбинации.
Добавление от Fikys: с Ruby работает.

Если вы знаете vim и tmux, и вам интересен только vim-slime — прыгайте сразу ко второй секции.

Вступление

Мы все стремимся быть производительными. После того, как код написан, мы хотим узнать, работает ли он и получить обратную связь. Мы придумали много способов ускорения обратной связи: статическое выведение типов при компиляции и в IDE, юнит-тесты, интеграционные тесты, REPL, LiveReload и т.д.

Для моих небольших проектов я использую связку REPL и юнит-тестов, что позволяет получать обратную связь мгновенно.

Я веб-разработчик. По работе и в своем проекте обычно я делаю фронтэнд и стыкующуюся с ним часть бэкэнда. В течении рабочей сессии я пишу PHP, phtml, Stylus, css, Coffeescript, Javascript, + sql запросики и пуши в гит; что обеспечивается связкой tmux и vim. Также есть пара маленьких проектов на CoffeeScript, для которых используется комбо tmux + vim + vim-slime + Coffeescript REPL. В проектной сессии увязываются Сlojure, CoffeeScript, Stylus; tmux + vim + vim-slime + Clojure REPL. Под катом я расскажу об трех сетапах для трех окружений.

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

Так бы оно и лежало в глубинах памяти, если бы не статья «Педалируем Vim». А тут как раз на столе валялись несколько аппаратных ключей на AT90USB162, что мы выпускаем для защиты своего софта.

В этом посте пойдёт речь о широко известной в узких кругах педали для переключения Vim из Normal mode в Insert mode и обратно. Вдохновившись примерами подобных поделок на просторах сети, я решил сделать свой вариант, с преферансом и поэтессами.

Задача

Сделать педаль, представляющую собой USB HID-устройство, при нажатии и удержании которой печатается i, а при отпускании Esc.

Решение

Заказать китайскую педаль PCsensor USB footswitch и запрограммировать её соответствующим образом.

Макросы в Vim

Очень странно, с одной стророны тема довольно банальная, а с другой ни тут, ни на просторах интернета не видно хорошего понимания такой важной темы, которая может иногда сильно упростить задачу редактирования текста. К написанию меня подтолкнуло обсуждение макросов в Emacs в блоге Avdi Grimm'а, где в своё время никто не смог внятно объяснить, что в Vim есть то, чего ожидает автор поста от достойного текстового редактора. Исправим это, в первую очередь в себе, а потом пойдём и скажем этим из интернета, что они не правы.

Какие задачи редактирования текста помогут решить макросы? Например, такую: вот в этой самой строке, которую вы читаете, взять и все запятые поменять на 0. Можно вспомнить регулярные выражения, но не все их любят, и уж тем более не все помнят, как вставлять с их помощью перенос строки, а если вам нужно заменять какие-то символы, которые используются в регулярных выражениях как служебные, вы уже отвлеклись от своей основной задачи и вместо редактирования текста занимаетесь написанием регулярного выражения для поиска и замены, пробуя и ошибаясь.
Макросы позволят это сделать быстрее, с меньшим отвлечением на вспоминание и написание чего-либо. Запомнить как работают макросы очень легко, и это войдёт в ваш ежедневный аресенал наряду с прыжками по тексту.

В этом топике мы научимся использовать макросы с этой самой задачей.

Давайте сначала вспомним, как это сделать вручную.
f,r0
После чего можно нажимать последовательно ; для повторного поиска и . для повторения предыдущего действия. Но в какой-то момент это может стать не так просто, например, вам нужно добавить пару каких-то знаков между делом. Точка уже не сработает и нужно будет опять нажимать r0. Или этих запятых окажется довольно много, и щёлкать поочерёдно ; и . придётся довольно много раз. В этот момент что-то вам уже подсказывает, что такой механический труд можно автоматизировать.

Основы
Многократные повторения и рекурсивный вызов
Редактирование макросов
Вечные макросы
Всякое

Данная статья будет посвящена настройке vim, в которой я поделюсь своим «скромным» пониманием того, каким должен быть текстовый редактор, чтобы в нем было удобно/приятно/легко (нужное подчеркнуть) писать код также, как это сейчас возможно во всевозможных IDE типа PyCharm, SublimeText и т.п.
Весь процесс постараюсь описать как можно более подробно, чтобы вопросов по мере чтения для начинающих осваивать vim возникало как можно меньше.

Vim — замечательный редактор, лучший выбор для программиста!

Краткий список причин, почему вам стоит его изучить:

1. Консольный интерфейс

Ваш любимый редактор готов в любой момент на любой машине.

2. Скроллинг

Чтобы переместиться на 42 строки ниже, достаточно просто набрать 42j, а если вы хотите пролистать документ на половину экрана ниже, тогда воспользуйтесь комбинацией Ctrl+d. И забудьте про скроллинг с использованием мыши (не говоря уже про трекпад). Просматривать код рывками без плавности интерфейса намного удобней!

3. Множественная замена (несколько курсоров)

Отличная фича! Не переживайте о том, что у вас ее нет. Вы всегда можете найти готовый плагин (тысячи их) или даже написать свой, если найденный не устроит.