VIM *

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

Гуглим, выясняется, что для превращения вима в нормальный редактор нужно нажать i. Только сохранить поредактированный текст нельзя, перед этим надо несколько раз нажать эскейп, а потом набрать :w. А, чтобы его закрыть, нужно нажать эскейп, а потом набрать :q. Тяжёлое наследие прошлого. Ну, зато вим есть везде.

Но в какой-нибудь из статей, рассказывающей, как провести 5 минут в виме и остаться в живых, обязательно будет написано, что вим — лучший текстовый редактор в мире. И ещё выяснится, что люди в нём программируют. То есть, натурально, пишут код. То есть, на дворе 21 век, в любой момент можно скачать Visual Studio, Intellij Idea или, прости господи, Eclipse, а они пишут код в виме. Добровольно.

«Чего-то здесь не хватает». Спорим, такая мысль первой придёт в вашу голову, если увидите моё рабочее место в офисе. Здесь нет монитора и мыши. Есть только парень, который молотит по клавиатуре, глядя словно в пустоту.



Это всего лишь я, и мои коллеги гарантируют вам, что я обычно не опасен. Я программист в офисе компании Vincit в Тампере (Финляндия). И ещё я слепой. В этой статье хочу немного рассказать, как я работаю.

На днях один популярный вопрос на Stack Overflow отпраздновал свой юбилейный миллионный просмотр.



Ты не одинок, jclancy. За пять лет, которые прошли, с тех пор как был опубликован этот пост, больше миллиона других разработчиков постигла та же участь — они застряли в Vim и не могли выбраться без посторонней помощи. Не зря в IT сообществе столько шуток о том, как трудно найти выход из этого редактора.

Всем привет. Я достаточно давно пользуюсь редактором Vim для редактирования очень разных текстов: правки конфигов, написания кода, в качестве внешнего редактора в браузере и почтовом клиенте…

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

От переводчика:

Некоторое время назад на Хабре публиковался перевод статьи под названием "Искусство командной строки". Среди прочего, в статье было рекомендовано освоить vim. Исходник статьи, выложенный на Гитхаб, по иронии судьбы, оказался совершенно непригодным к редактированию именно этим редактором, так как в нём на один абзац приходилась ровно одна строка.

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

Хочу предупредить, что не все ссылки в статье работоспособны, но я решил оставить их как есть — мало ли что.

Предлагаю читателям "Хабрахабра" перевод статьи "Why, oh WHY, do those #?@! nutheads use vi?" за авторством John Beltran de Heredia.

Да, даже если вы не можете в это поверить, у редактора vi, увидевшего свет более тридцати лет назад (и его более молодого, всего-то пятнадцатилетнего лучшего клона & большого улучшения — vim) очень много фанатов.

Нет, они не динозавры, которые не хотят идти в ногу со временем — сообщество пользователей vi продолжает увеличиваться: я, который начал только два года назад (после десяти лет работы программистом). Мои друзья переходят на vi сейчас. Черт, большинство пользователей vi даже еще не были рождены, когда он был написан!

Да, есть конкретные причины, почему модель редактирования vi/vim превосходит любую другую. Вам не надо быть экспертом в Unix, чтобы использовать vi — он доступен бесплатно практически для любой существующей платформы; для большинства IDE существуют плагины, позволяющие использовать его возможности. Давайте же развеем некоторые заблуждения и рассмотрим пару примеров, демонстрирующих его превосходство.

Сегодня вышел текст о том, как человек перешёл с Sublime на VIM. В комментариях, как обычно это бывает, появились сообщения в духе "Зачем мне тратить время на Vim, если есть IDE, где всё работает?" (люди даже статьи на эти темы пишут). Хотел внести свои пять копеек, но объём написанного плавно перевёл текст из разряда "комментарий" в разряд небольшой статьи.

В целом, всё, что ниже — это вкусовщина, конечно. Нравится вам ваша IDE (или ваш текущий инструмент), да и пожалуйста. Используйте для текущих задач то, чем вы владеете лучше всего, это аксиома эффективной работы. Но если у вас вдруг появилось немного времени на повышение вашей эффективности в целом, то попробую вас заинтересовать именно Vim'ом, сравнивая его с некой обобщенной IDE.

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

Я достаточно долгое время использовал sublime (около 4 лет) в качестве основной среды разработки, но в последнее время кое-что изменилось: я освоил слепой 9-ти пальцевый метод печати. В тот момент я начал понимать людей, которым неудобно тянуться к мышке или стрелочкам. Убирать пальцы с «домашних» позиций стало неестественно и непродуктивно. Тогда я включил vintage. Проблема, вроде бы, стала неактуальна, но чего-то не хватало. Не помню, что заставило меня пересесть за vim, но мне всегда нравилось, как в нем выделяются фигурные скобки (MatchParen) и как выглядит курсор :). 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 плагинов.

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

Компания, где я работаю, разрабатывает программное обеспечение на 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», если вам так хочется.

В этом посте пойдёт речь о широко известной в узких кругах педали для переключения 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 возникало как можно меньше.

В один прекрасный день надоедает нажимать Shift, чтобы вывелся символ ~ вместо `.
Надоедает тянуться до Esc, при этом клавишей CapsLock пользуетесь РЕДКО.
Надоедает смещать кисть вниз и нажимать Ctrl/Cmd/Win слабым мизинчиком, либо, не дай бог, тянуться до них большим пальцем.
Надоедает лезть за PgUp, PgDn, Home и End, двигая руку каждый раз, чтобы всего лишь промотать страницу вниз.
Надоедает каждый раз, когда вы делаете опечатку, со злобой смотреть на клавиатуру в поисках кнопки Backspace.



Сегодня мы узнаем, как навсегда избавиться от этих мучений.

Зачем это всё?

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

Многие раскладки для печати (Dvorak, Colemak и т.п.) сильно улучшают расположение клавиш, ставя их ближе к тем местам, куда нужно меньше тянуться. Но при этом совершенно забывают о модификаторах, спец. символах и командных клавишах (Enter, Backspace, Tab, Esc, Delete). А мы подумаем о том, как улучшить существующее положение вещей.

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

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

Сегодня я хочу рассказать, как я использую Vim в качестве IDE для C/C++ проектов.

Несмотря на то, что я использую Vim для C/C++, многие из рекоммендаций довольно общие и могут использоваться в любом проекте.