CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
22.08.2017

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Приложения

Заметки

Почему - VIM?

Версия 2007.02.19, posix.ru
Впервые опубликовано: LinuxFormat, 2006, 78

€ 15 — за что?!

Недавно увидел предложение: plugin для VIM, обеспечивающий его интеграцию в Eclipse. Недорого — всего 15 евро. Если кто-то не знает, Eclipse — кроссплатформенная интегрированная среда разработки, иначе говоря — IDE. Из этого следует, что свой редактор в Eclipse обязательно входит. Кому же может потребоваться интеграция Eclipse с VIM, да ещё и "не даром"? Кому-то, как выясняется, требуется. Что же это за "динозавр" такой, если его качества кажутся не лишними для современной IDE? Или это просто "дань уважения традиции"? Без выяснения, что же такое VIM, ответить на этот вопрос не удастся.

Тридцать лет — это возраст...

Все нынешние потомки VI (а их нынче полтора десятка для всех наиболее популярных ОС) имеют общего предка - VIsual editor Била Джоя (Bill Joy), написанный в 1976 году. История, типичная для времени становления UNIX: несколько прототипов (ed/em/ex), несколько оригинальных идей, коллективное творчество... и удачный продукт, если повезёт. По мнению самого Джоя, от EMACS его редактор изначально отличали, прежде всего:

  • мультирежимность (mode-based edidting);
  • не-программируемость;
  • цена (EMACS в те времена стоил несколько сот долларов).

Иными словами: никаких особенных претензий. Доступность редактора, по мнению Джоя, была единственным основанием его включения во многие UNIX-системы в качестве базового. Глядя из 2006-го, поневоле задумаешься: а ведь, похоже, будущие принципы open source "угадывались" уже в далёкие 70-е...

Так изначальная простота и доступность обеспечили распространение VI. Без сомнения, их можно занести в актив программы и сейчас. Открытость гарантировала наращиваемость (результат — почти 4-х мегабайтный в исходных текстах VIMproved Брэма Моолинаара (Bram Moolinaar)), а простота приводит к тому, что если нужно выбрать редактор для встроенной системы (см. busybox), то это, вполне вероятно, будет vi. Похоже, тридцать лет прошли не напрасно.

UNIX-ово племя

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

Во-первых, сам VIM следует принципам UNIX, насколько это только возможно для редактора. Последовательное воплощение принципа KISS (Keep It Simple, Stupid!) не всегда реализуемо (не так часто VIM становится звеном цепочек обработки и прочих pipe-ов), но стремление следовать "заветам" налицо. Во всяком случае, перенаправление вывода команды в редактируемый текст и, наоборот, использование части текста в качестве команды, широкое использование "конвейерной" обработки и т.п. неизменно радуют сердце юниксоида. В VIM нет проверки правописания, но есть всё необходимое для использования любого из наличных в системе spellchecker-ов. И так со всеми сопутствующими редактированию процессами. Потребовалось редактирование двоичных файлов — добавим простейший конвертер, а редактор текста пусть останется редактором текста.

Во-вторых, UNIX, для которого текстовые файлы — "плоть от плоти", сам "благоволит" к VI и его потомкам. Многие программы вызывают VI как "штатное" средство редактирования, "горячие клавиши" VI, часто используются в том же качестве другими программами, существует стиль редактирования vi и даже bash, по умолчанию предлагающий стиль редактирования строки emacs, допускает переназначение переменной editing-mode на 'vi'. Общий подход прослеживается при использовании регулярных выражений и т.д. и т.п. Возможно, <Ctrl>+<F> для поиска выглядит и более логично (если под F подразумевать Find, то есть "находить"), но привычное для vi нажатие "/" (слэш), как ни странно, даст желаемый результат что при просмотре man-страниц, что в links, что в mcеdit.

Чуть подробнее

VIM последовательно (иногда даже навязчиво) придерживается программистской логики: есть объекты (символ, слово, строка, предложение, параграф, блок) и есть действия (позиционирование, копирование, удаление, вставка, замена и т.д). Все действия возможны над всеми объектами от одного до N раз. Откуда следует универсальная команда, подобная следующей:

[N раз] { идентификатор действия } [ идентификатор объекта ]

Теперь нужно оптимизировать принципы идентификации объектов и ввода команд. Результат, кстати, будет зависеть от пожеланий пользователя и устройств ввода и отображения (напомню: зарождалась эта идеология во времена довольно разнообразных терминалов). Кому-то представляется достаточной система меню, кому-то - "горячие" клавиши, а кто-то предпочтёт и исключающую двусмысленность командную строку. VIM это уже не волнует: обеспечив возможность выбора, авторы предоставляю пользователю дальнейшее развитие продукта. Логично, поскольку программа открыта и бесплатна: нет никаких оснований тратить время на её "упаковку", ориентированную на ту или иную целевую группу (имею в виду хорошо известные маркетологам target groups).

Подобная "жёсткая" логика в применении к файлам выглядит следующим образом:

  • файлы можно создавать, удалять, читать из них, писать в них;
  • открытому файлу соответствует буфер;
  • окно предоставляет доступ к отдельному буферу.

Разумеется, число открытых файлов (и соответствующих им буферов) ничем не ограничивается.
Разумеется, число окон ограничивается только здравым смыслом и площадью экрана.
Разумеется, число окон никак не связано с числом буферов (открытых файлов).
Разумеется, окна могут делить экран как угодно (по горизонтали, по вертикали).
Разумеется, есть множество команд, выполняющих все возможные (иногда: непонятно зачем) действия над файлами, буферами и окнами. А выбор (меню, "горячая клавиша" или командная строка) — за пользователем.

Создаётся впечатление, что задумывался универсальный инструмент работы с текстом, а как именно будет его применять пользователь — предоставили решать ему самому. Всё многообразие команд не помещается ни меню, ни в набор "горячих клавиш". Можно, конечно, свести все действия к командной строке с двумя режимами: редактирования и командным. Либо - редактируем, либо - вводим команду: просто, определённо и... утомительно. Так появились дополнительные режимы. Вообще-то у VIM шесть основных режимов и пять дополнительных — мало не покажется. Но и пугаться особенно не стоит: кроме само собой разумеющихся режимов редактирования ("вставки") и командного (скромно именуемого нормальным или обычным), для начала достаточно знать ещё визуальный (перемещение курсора изменяет область выделения) и "замены" (вводимые символы "замещают" содержимое буфера, а не дополняют его).

Переключение между режимами, не очевидное на первых порах, также трудностей не вызывает: Одно-два нажатия <Esc> всегда вернут в нормальный режим, первый <Ins> переводит в режим "вставки", второй - "замены". <v>, <V> или <Ctrl>+<V> обеспечивают переход из нормального режима в визуальный, причём выделение будет выполняться посимвольно, по строкам или в виде прямоугольного блока — в зависимости от того, который из перечисленных символов введен.

На этом первое знакомство c VIM можно и закончить: не предполагали же вы, что данная статья заменит вам 4 МБ документации в текстовом формате? Справедливости ради отметим, что 3.5 МБ из 4 - это встроенная система помощи (она же — Reference Guide). Для чтения больше подходят оставшиеся 0.5 МБ User's Guide. Но и это не мало — не правда ли?

На этом этапе впору задуматься: если знакомство с VIM так трудоёмко, то стоит ли этим заниматься вообще? Ситуация напоминает первое знакомство с Linux: есть желание и (хочется верить) способность разобраться, но чтобы было с чем разбираться, надо сначала инсталлировать. А вот на это-то у "неофита" то ли знаний, то ли терпения может и не хватить... Что ни говори, а знакомиться с с уже работающей "игрушкой" намного интереснее, чем читать документацию, постоянно мысленно возвращаясь к одному и тому же вопросу: зачем?

Можно надеяться, что с современными инсталляциями VIM так не случится: и учебничек на русском языке к нему прилагается (запускается просто: vimtutor, проверьте только, чтобы /usr/share/vim/vimNM/tutor/tutor указывал на tutor.ru), и сам он по-русски общается с пользователем довольно сносно, а если ментейнер дистрибутива позаботился ещё и о более-менее полных вариантах vimrc_example.vim (из которого следует немедля сделать ~/.vimrc) и menu.vim, то "игрушку" можно признать вполне работоспособной. А уж насколько она окажется полезной — зависит только от пользователя.

Осталось выяснить: нужно ли это вам вообще? Если с текстом случается работать лишь изредка, то скажем прямо: нет. VIM включает в себя в качестве расширений и игрушки (всем известный Tetris и Башню Ханоя, например), но только из-за этого связываться с ним не стоит. Общее знакомство может пригодиться в тот несчастливый день, когда вы окажетесь один на один с чёрным экраном консоли и каким-нибудь rescue-cd (последний других средств редактирования файлов может и не иметь), если, конечно, вспомните к тому моменту хотя бы команды открытия/закрытия файлов (именно на этот случай мы прилагаем во врезке краткий список "тривиальных" команд, доступных даже в самых усечённых реализациях VI).

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

Что особенного-то?

Кроме упомянутых выше неограниченного числа буферов (открытых файлов) и произвольного числа окон, хочется отметить возможности VIM, несколько выходящие за пределы стандартных:

  • VIM работает в текстовом режиме на большинстве терминалов, но для любителей есть и графический интерфейс (то есть меню и поддержка мыши). Излишняя в эру IBM PC поддержка терминалов оказывается очень кстати при открытии сессии на удалённом компьютере. Согласитесь, что просмотр логов или редактирование конфигурационных файлов сервера, у которого, может, и терминала-то нет, удобнее выполнять с помощью привычного редактора;
  • VIM выполняет автодополнение строк, слов, имён файлов и команд. В зависимости от контекста (режима) и формы запроса (определяется последовательностью "горячих клавиш") в качестве вариантов будут предложены слова или строки из текущего и подключаемых файлов, так называемых 'dictionary' и 'thesaurus', имена открытых файлов, описанные определения и макросы либо допустимые элементы командной строки;
  • VIM поддерживает редактирование "справа налево" (Арабский, Персидский, Иврит) и многобайтовые символы (Китайский, Японский, Корейский), не говоря уже обо всех 8-битных кодировках кириллицы плюс, разумеется, UTF-8 и Unicode;
  • VIM умеет выполнять автокоманды: выполнение определённых действий в зависимости, например, от типа файлов;
  • помимо обычных в наше время "undo" и "redo", VIM сохраняет "историю" команд и поисков, так что их можно повторно использовать, а, при желании, и редактировать;
  • количественный префикс (см. выше "универсальную команду") позволяет указывать количество повторений для большинства команд;
  • VIM сохраняет информацию о редактировании в текстовом файле ~/.viminfo. Эта информация позволяет не только восстановить сеанс редактирования после краха, но и иметь своеобразную "заготовку" среды редактирования — нечто вроде "проекта" со своим списком открытых файлов, шаблонов и макрокоманд;
  • гордость последних версий MS Office, многостраничный буфер обмена, присутствует в VIM в форме регистров — нумерованных (для cut/copy/paste) и именованных, обращение к которым задаётся в явном виде. Содержимое именованных регистров может, кроме того, накапливаться (нечто вроде Memory+ у калькулятора), а также использоваться, как команда. Плюс несколько специальных регистров (последняя вставка, команда, файл, буфер обмена X Window);
  • для облегчения поиска VIM может расставлять в тексте собственные метки, а может использовать систему "тегов" для индексирования текста. Эдакий "markup language" в миниатюре;
  • VIM поддерживает так называемые "складки" (foldings): часть текста, определяемая вручную, в зависимости от отступа либо в соответствии с синтаксисом или специальными маркерами как бы "складывается", оставляя после себя лишь пунктирную линию с символом "+" в первой позиции. Полезность такого "складывания" становится очевидной после запуска, например, 'vimdiff today.dmp  yesterday.dmp' где today.dmp и yesterday.dmp — мегабайтные дампы одной и той же БД, полученные сегодня и вчера соответственно. Результат будет представлен в виде соседствующих по вертикали окон, каждое из которых покажет только не совпадающие фрагменты файлов: совпадающие будут "сложены".

Не думаю, что список получился исчерпывающим, но для начала и этого более чем достаточно.

А вот ещё несколько менее оригинальных, но весьма полезных возможностей:

  • поиск в произвольном направлении лексемы "под курсором";
  • поиск "определения" лексемы "под курсором";
  • полностью настраиваемая автоподсветка синтаксиса для множества типов файлов с возможностью создания типов собственных. В настоящее время в стандартную поставку входит свыше четырёхсот файлов-описателей синтаксиса языков программирования, конфигурационных файлов и логов;
  • всеобъемлющие help-файлы плюс руководство пользователя;
  • встроенный скриптовый язык для добавления новых возможностей;
  • система plugin-ов;
  • ввод специальных символов комбинацией двух символов, причём возможно определение собственных комбинаций;
  • автоматическое определение типа файла (DOS, Mac, Unix) с возможностью сохранения в любом из этих форматов;
  • запись действий пользователя в виде макросов — для выполнения повторяющихся операций;
  • выделение символов, строк и прямоугольных блоков;
  • редактирование в "виртуальном" режиме, когда пустые позиции автоматически заменяются пробелами — незаменимое средство при составлении таблиц;
  • замена символов табуляции на пробелы;
  • повторение последнего действия, каким бы сложным оно ни было;
  • интеграция с Perl, Tcl и Python: можно расширить функциональность редактора, написав функцию на языке, более предпочтительном, чем собственный язык VIM, а можно просто выполнять какие-то действия якобы в любимом интерпретаторе, используя, на самом деле, модуль того же редактора.

И многое, многое другое.

Программистам от программистов.

Бытует мнение, что VIM написан "программистами для программистов". Не думаю, что это настолько справедливо, что не-программист не найдёт в VIM ничего полезного. Тем более, что сейчас уже совершенно неясно: увлеченно "ваяющего" личную web-страничку нужно уже относить к программистам или ещё нет? Тем не менее, не заметить, что именно программисты — наибольшие поклонники VIM, невозможно. В качестве иллюстрации ниже следует описание одного сеанса работы. Итак...

  • Запуском vim без параметров я заставляю его предварительно считать ~/.viminfo. В результате к моменту начала редактирования уже открыты три файла, с которыми я работал в последний раз. Убеждаюсь в этом, нажимая F12 и переключая при этом буфера (в ~/.vimrc имеется строка
        map! <F12> <Esc>:bn<CR>
    
    
    которая для всех режимов (!) по нажатию F12 (map <F12>) выполняет (на всякий случай) перевод в нормальный режим (<Esc>) и ввод команды (:bn - вывести в текущее окно следующий в списке буфер). Ввод команды завершается <CR>).
  • Поскольку опция set viminfo всё в том же ~/.vimrc содержит, среди прочего, и параметр f1 (сохранять файловую отметку '0, соответствующую текущему положению курсора в момент завершения последнего сеанса), то для всех буферов (файлов) курсор будет установлен в ту позицию, где он находился перед закрытием.
  • Нажатием F5+S~/.vimrc имеется 'map! <F5> <Esc><C-W>' , которая "привязывает" к нажатию F5 все команды манипуляций с окнами) получаю два расположенных друг под другом окна, в каждом из которых по одному нужному в настоящий момент буферу (файлу). Разумеется, размер окон меняется. Разумеется, ненужное окно всегда можно закрыть нажатием F10~/.vimrc имеется 'map! <F10> <Esc>:q<CR>'). На буферах это, кстати, никак не отражается, и вплоть до закрытия последнего окна об их судьбе можно не беспокоиться. При закрытии последнего окна, которое логически соответствует выходу из программы, VIM напомнит о наличии в памяти буферов, сохранение которых в файл не выполнялось.
  • Сохранение, как довольно частую операцию, я "привязал" к F2~/.vimrc имеется 'map <F2> <Esc>:w<CR>').
  • Разумеется, VIM "раскрашивает" содержимое файлов в соответствии с синтаксисом соответствующего языка. Практически невозможно сделать ошибку в написании оператора или базовой библиотечной функции, пропустить символ, отделяющий комментарий и т.п. В своё время, VIM "помирил" мою лень с рекомендацией давать переменным, функциям, классам и методам полные, исчерпывающие имена: почему бы и нет, если это делается один раз, а впоследствии автодополнение сделает ненужным полный набор, исключая при этом вероятные ошибки.
  • Разумеется, VIM выполняет "autoindent" - блоки программы автоматически выделяются соответствующими отступами. Ввод закрывающей скобки любого типа буквально на секунду услужливо перенесёт курсор на соответствующую открывающую скобку, если она в пределах экрана. Если же конструкция достаточно сложна и соответствующую открывающую скобку "ещё поискать", то на помощь придёт "matching": нажатие '%' в нормальном режиме и курсоре на скобке переносит курсор на соответствующую скобку.
  • Потребуйся мне невзначай код какого-либо символа, нажатие <g><a> даст полную информацию о символе под курсором.
  • Операции с регулярными выражениями — на очень высоком уровне. Не Perl, но для редактирования - более чем достаточно. Поиск и замена становятся столь эффективны, что на приведение в "приличный" вид мегабайтного html-файла из-под MS Word (а вы когда-нибудь видели, как выглядит html в исполнении Word?) уходит 10..15 минут.

Программисты, как и пешеходы, составляют лучшую часть населения, однако, в отличие от последних, отнюдь не большую. Поэтому описание прелестей VIM для программистов на этом прекращаем и переходим к ответу на вопрос: насколько этот "дедушка"-редактор вписывается в современный графический десктоп?

А как в X-ах?

С воцарением в Linux framebuffer и всё большим распространением LCD мониторов стоит, возможно, пересмотреть отношение к редактированию текста в консольном режиме. В самом деле: поле редактирования — 128х50 символов при диагонали 15", цвет фона и символов — любой, частота кадров — 70 Гц, да и не важно это для LCD. Terminus — практически безукоризнен в качестве моноширинного фонта, а для текстов программ как раз моноширинный-то и предпочтителен... Вернёмся, однако к X-ам.

Как это ни странно, но терминал-ориентированый VIM и в графической среде достаточно неплох, причём во всех доминирующих графических окружениях. Сам по себе VIM, скомпилированный с соответствующими опциями (а именно так большинство ментейнеров и делает) и получивший ещё одно (на сей раз - символическое) имя — gvim, использует gtk, но особого сродства к Gnome при этом не демонстрирует (разве что иконки указывают на это). Разработчики KDE благоволили к VIM настолько, что долгое время поддерживали проект под названием kvim, но это, к сожалению, в прошлом. В настоящее время в центре управления KDE (ветка "Компоненты KDE") можно найти позицию "Встраивание VIM", воспользовавшись которой, можно сделать gvim средством редактирования "по умолчанию" и придав ему при этом некоторую QT-шность. Два ряда иконок (одна от gvim, одна — от KDE) выглядят несколько курьёзно, но не будем привередливы: в любом случае, это всё тот же VIM. Более-менее существенные отличия сводятся к трём пунктам:

  • поддержка мыши (в консольном варианте её обеспечивает gpm, соответственно, она опциональна);
  • меню, которое в консольном варианте также опционально, для gvim — неотъемлемый компонент;
  • использование возможностей X Window (доступ к общему буферу обмена без использования специальных регистров, произвольно задаваемые фонты и т.п.).

Замечательно, что помимо ~/.gvimrc (а как, вы полагали задаётся конфигурация gvim?), учитываются все опции, перечисленные в ~/.vimrc. Таким образом, опыт и приёмы консоли практически наследуются. А вдобавок мы получаем набор иконок для самых распространённых действий и меню, настолько исчерпывающее, насколько вы сами или ментейнер дистрибутива позаботились об этом.

Особенно радует ожившее колёсико мыши (gpm его не поддерживает, но Х-ы - поддерживают вполне) и позиционирование курсора кликом левого бутона. При этом привычные способы выделения (начало блока - клик левым бутоном, конец - правым) и вставки (нажатием среднего бутона (колёсика)) работают по-прежнему.

Настоящим продолжателем традиций VIM в графической среде может стать YZIS, а, точнее, kyzis — его QT-реализация, доступная в Сети по адресу http://www.yzis.org/. Проект пока далёк от завершения, но уже сейчас можно видеть, что он удачно сочетает в себе графическую лаконичность QT и идеологию VIM.

Одним словом, в графической среде VIM ничего не потерял и даже кое-что приобрёл. Остаётся только пожелать того же другим unix-"дедушкам".

А стоит ли беспокоиться?

Убеждать пользователя в необходимости изучения того или иного программного продукта — занятие бесперспективное. Тот, кем движет любопытство, в подобном не нуждается, а "всем довольному" — какой смысл затрачивать дополнительные усилия? Освоение сколько-нибудь сложного инструмента становится необходимостью только тогда, когда обещает выигрыш в работе. Множество программистов во всём мире считают использование VIM в своей работе оправданным. Каждый из них когда-то решил, что затраты на изучение хорошего инструмента пренебрежимо малы в сравнении с ожидаемой пользой. А каждый новый потенциальный пользователь будет решать этот вопрос для себя сам.

На первый взгляд, знакомство лучше начинать с gvim или kyzis — из них хоть выйти можно без поиска соответствующей команды. Но, в то же время, чем такой "причёсанный" VIM лучше joe или mcedit — не очевидно. Так что сначала лучше бы почитать что-то вроде этой статьи: где-нибудь да отложится информация о существовании у VIM неких неординарных возможностей. Далее стоит поискать задачу, для решения которой в joe или mcedit нужно так долго нажимать клавиши, что и приступать к этому не хочется. Ну, а потом можно попытаться эту задачу решить с помощью VIM.

А вот если задача будет решена и инструмент продемонстрирует, что стоил потраченного на знакомство с ним времени, — тогда имеет смысл перейти к его "приручению". Лучшие, на мой взгляд, источники информации для этого перечислены во врезке "А дальше..."

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

VI-минимум

Ещё раз напомним, что главное при работе в VI — контролировать, в каком режиме находится редактор. Нормальному режиму соответствует пустая нижняя строка экрана. Все остальные режимы индицируются надписью в левом нижнем углу. <Esc> всегда возвращает в нормальный режим, <Ins> переводит в режим "вставки"/"замены" (экранное редактирование), <v> переводит в визуальный режим (режим выделений).
В нормальном режиме возможны:

  • :e file - открытие существующего или создание нового файла;
  • :w [file] - сохранение буфера в "свой" или новый файл. :w! - невзирая на защиту записи ;
  • <Ctrl-G> - дать полную информацию об открытом файле и положении курсора в его буфере;
  • :q - закрытие окна (для последнего окна - выход из редактора). :q! - невзирая на наличие несохранённых буферов;
  • :!command - выполнить внешнюю команду;
  • :bn - переключиться на следующий буфер;
  • <Ctrl-W>s - разделить окно пополам по горизонтали, <Ctrl-W>v - по вертикали;
  • <Ctrl-W>w - перейти в следующее окно;
  • d - удалить символ с помещением в регистр обмена, dd - строку;
  • y - копировать в регистр обмена символ, , yy - строку;
  • [p, ]p - вставить из регистра после или перед курсором;
  • :r file - вставить содержимое файла;
  • /string - искать string (строка или регулярное выражение) от курсора и ниже;
  • ?string - искать string выше от курсора;
  • n или N - продолжить поиск ниже или выше по тексту;
  • %s/string_old/string_new - замена во всём буфере;
  • * - найти следующее вхождение слова под курсором, # - предыдущее;
  • % - найти ответную скобку;
  • . - повторить последнюю операцию;
  • [n]G - перейти на строку n, в отсутствие n — в конец файла;
  • ) или ( следующее или предыдущее предложение, для }/{ — параграф, для ]]/[[ — секция, функция;
  • mx - пометить текущую позицию буквой x;
  • `x - перейти к метке x;
  • ~ - изменить регистр символа под курсором;
  • u - "undo", U - восстановить всю строку;
  • <Ctrl-R> - "undo the undo's".

Список весьма неполон и, наверное, субъективен, но что поделаешь — полное описание только способов позиционирования будет иметь объём больший, чем весь наш "минимум". А ведь есть ещё команды удаления, замены, информационные...

В визуальном режиме d и y в качестве объекта подразумевают выделение, как и меняющие регистр u/U.

О режиме "вставки" (поскольку мы говорим практически исключительно об IBM PC) достаточно сказать, что работают все клавиши позиционирования курсора. Хоть это и не вся правда, но напомним: данный минимум предназначен только для того, чтобы справиться со "спартанскими" вариантами VI из состава busybox или crunchbox.

А дальше...

Вполне вероятно, что когда-нибудь вам потребуется пересобрать VIM. Меня, во всяком случае, когда-то не устроили сборки ни RedHat, ни Alt, ни ASP. Было это уже давненько, возможно, положение и изменилось, но я по-прежнему предпочитаю VIM собирать сам — всё-таки это самая используемая программа. Исходники находятся на http://www.vim.org/.

Современные версии VIM успешно "разговаривают" по русски, а вот за русским help и User Guide стоит сходить на http://www.sf.net/projects/ruvim. Эти переводы несколько устарели — вряд ли стоит заменять ими оригинальные файлы, но для чтения они незаменимы.

Вне конкуренции находится проект Vim Online (адрес: http://vim.sourceforge.net/). Возможно, именно с него стоит начинать, если вы никак не определитесь, нужен ли вам VIM. Свыше тысячи советов, почти полторы тысячи скриптов. И чего только с помощью VIM не делают...

Сайт Гомера Джила (Thomer M. Gil) — ещё одна общепризнанная точка старта в VIM-путешествие. Адрес: http://thomer.com/vi/vi.html.

Список русскоязычных ресурсов также достаточно внушителен.На CitForum.ru можно прочитать "Поваренную книгу VIM".

А на www.vnc.org.ua лежит перевод полновесного HOW-TO.

Почти хрестоматийный "Путь к VIM" Ильи Ялового можно найти на www.opennet.ru.

Хороший справочник предлагает Роман Савоченко: "VIM — кратко обо всём".

Автор также внёс свою лепту:




Комментарии

Страницы комментариев: 1 :: 2 :: 3 :: следующая

аноним, Tue Jun 23 17:11:17 2009:
"Поваренная книга VIM" по той ссылке недоступна. Вот верная - http://citkit.ru/articles/140/
аноним, Thu Jan 22 19:27:00 2009:
случайно наткулся на эту ссылку... А тут по моему труду проехались катком...

мне кажется что с Юникс подобными системами в принципе не получится работать интуитивно. Командная строка. Поэтому к трудностям человек должен быть готов :) :) :)

По поводу Vim можно спорить долго, но какой в этом смысл?
аноним, Tue Oct 23 00:24:59 2007:
>Алексей Федорчук
>2 027
>приглашение - и Вам

Спасибо. Зарегистрировался, но потерпел неудачу при активации. Отписал в саппорт.
ЗЫ. Жаль, что линуксфорум работает на глюкавом монстре IPB. Чудовишно толстые страницы, забитые всякой ненужной хренью, а лайт-версия, увы, ридонли. И чего людям на пхпбб не живется?..
Алексей Федорчук, Mon Oct 22 09:12:10 2007:
2 Доброжелатель, понедельник, 22 октября 2007 г. > Кто виноват и что делать? ;)
Кто виновать? - хвостер
Что делать? - написать мне alv собака домен позикса и получить временный пароль
Доброжелатель, Mon Oct 22 02:31:46 2007:
//
//
//
To: Алексей Федорчук

На Вашем форуме, к сожалению, не получается зарегистрироваться.

Программа пишет следующее:

Error: Unable to send e-mail. Please contact the forum administrator with the following error message reported by the SMTP server: "550 Relay denied ".


Кто виноват и что делать? ;)
Доброжелатель, Sat Oct 20 16:57:33 2007:
*

2 Алексей Федорчук


// Это можно сказать про все юниксовые редакторы
--------------------

Пожалуй так. Лично у меня основные трудности возникают из-за различий клавиатурных комбинаций в виме и емаксе. Ничто, конечно, не мешает использовать «для всего» лишь один из этих друх замечательных редакторов, но есть, всё-таки, отличия. Например, для емакса есть такая нужная штука как AucTeX. А в виме удобно перловые скрипты писать, и вообще редактировать текст, а уж о файлах настроек и говорить не приходится.

Кстати сказать, где-то в интернете мне встречались упоминания о том, что редакторы, отличные от vi(m), иногда бывают причастны к порче конфигурационных файлов. Впрочем, это всё лирика.

Для меня своего рода ушатом холодной воды стало отсутствие вима (или хотя бы чего-то наподобие ее) в базовой установке OpenBSD. Поневоле приходит на ум старая шутка о режимах работы vi — пищит/не пищит. :)


// Не только. Трудности с Vim'ом возникают у старых пользователей DOS, которые привыкли к emacs-подобным кейбиндингам редакторов типа Микростара много лет назад - и на рефлекторном уровне.
--------------------

Не стану спорить. К моему стыду ли, гордости ли, но ДОСа почти не знаю, знакомство лишь эпизодическое, так что за это не скажу. :)

А нужно его знать? ;) Хотя, наверное, нужно — программистам. Если не ошибаюсь, до сих пор BIOS и DOS как-то пересекаются в использовании прерываний. Автор программы для восстановления/ремонта жёстких дисков Victoria в качестве аргументов за использование ДОСа пишет, что для некоторых задач именно ДОС, с его однозадачностью и сравнительной «близостью» к аппаратным ресурсам, подходит наилучшим образом. Правда он (автор) использует один из свободных клонов ДОСа.


// Написан. Будет в ближайшей рассылке :)

--------------------

Читатели ждут. :)



P. S.

Жуткая здесь система комментирования и вообще отображения материала. К кому обратиться с дельным предложением?
Доброжелатель, Sat Oct 20 16:57:30 2007:
*

2 Алексей Федорчук


// Это можно сказать про все юниксовые редакторы
--------------------

Пожалуй так. Лично у меня основные трудности возникают из-за различий клавиатурных комбинаций в виме и емаксе. Ничто, конечно, не мешает использовать «для всего» лишь один из этих друх замечательных редакторов, но есть, всё-таки, отличия. Например, для емакса есть такая нужная штука как AucTeX. А в виме удобно перловые скрипты писать, и вообще редактировать текст, а уж о файлах настроек и говорить не приходится.

Кстати сказать, где-то в интернете мне встречались упоминания о том, что редакторы, отличные от vi(m), иногда бывают причастны к порче конфигурационных файлов. Впрочем, это всё лирика.

Для меня своего рода ушатом холодной воды стало отсутствие вима (или хотя бы чего-то наподобие ее) в базовой установке OpenBSD. Поневоле приходит на ум старая шутка о режимах работы vi — пищит/не пищит. :)


// Не только. Трудности с Vim'ом возникают у старых пользователей DOS, которые привыкли к emacs-подобным кейбиндингам редакторов типа Микростара много лет назад - и на рефлекторном уровне.
--------------------

Не стану спорить. К моему стыду ли, гордости ли, но ДОСа почти не знаю, знакомство лишь эпизодическое, так что за это не скажу. :)

А нужно его знать? ;) Хотя, наверное, нужно — программистам. Если не ошибаюсь, до сих пор BIOS и DOS как-то пересекаются в использовании прерываний. Автор программы для восстановления/ремонта жёстких дисков Victoria в качестве аргументов за использование ДОСа пишет, что для некоторых задач именно ДОС, с его однозадачностью и сравнительной «близостью» к аппаратным ресурсам, подходит наилучшим образом. Правда он (автор) использует один из свободных клонов ДОСа.


// Написан. Будет в ближайшей рассылке :)

--------------------

Читатели ждут. :)



P. S.

Жуткая здесь система комментирования и вообще отображения материала. К кому обратиться с дельным предложением?
Алексей Федорчук, Sat Oct 20 16:37:59 2007:
2 Доброжелатель
Понимаете, система комментов к текстам не задумывалась как форум, а именно комменты по ходу дела:
прочитал статью, есть пара минут - чиркнул типа - вот здесь автор ошибся, об этом не сказал, у этой проге вышла новая версия,
и так далее.
Посему, если интересно обсуждение темы текстовых редакторов, предлагаю перенести его сюда:
http://forum.posix.ru/viewtopic.php?id=803
Если будут проблемы с регистрацией - а они будут, это типа барьера - пишите.

2 027
приглашение - и Вам

2 All
всем желающим поговорить на эту тему.
Сразу предупреждаю только: анонизмообразных существ (или веществ) там мочат сразу: в сортире, около сортира, и в любых других местах...
Доброжелатель, Sat Oct 20 16:15:36 2007:
*

2 Алексей Федорчук


// Это можно сказать про все юниксовые редакторы
--------------------

Пожалуй так. Лично у меня основные трудности возникают из-за различий клавиатурных комбинаций в виме и емаксе. Ничто, конечно, не мешает использовать «для всего» лишь один из этих друх замечательных редакторов, но есть, всё-таки, отличия. Например, для емакса есть такая нужная штука как AucTeX. А в виме удобно перловые скрипты писать, и вообще редактировать текст, а уж о файлах настроек и говорить не приходится.

Кстати сказать, где-то в интернете мне встречались упоминания о том, что редакторы, отличные от vi(m), иногда бывают причастны к порче конфигурационных файлов. Впрочем, это всё лирика.

Для меня своего рода ушатом холодной воды стало отсутствие вима (или хотя бы чего-то наподобие ее) в базовой установке OpenBSD. Поневоле приходит на ум старая шутка о режимах работы vi — пищит/не пищит. :)


// Не только. Трудности с Vim'ом возникают у старых пользователей DOS, которые привыкли к emacs-подобным кейбиндингам редакторов типа Микростара много лет назад - и на рефлекторном уровне.
--------------------

Не стану спорить. К моему стыду ли, гордости ли, но ДОСа почти не знаю, знакомство лишь эпизодическое, так что за это не скажу. :)

А нужно его знать? ;) Хотя, наверное, нужно — программистам. Если не ошибаюсь, до сих пор BIOS и DOS как-то пересекаются в использовании прерываний. Автор программы для восстановления/ремонта жёстких дисков Victoria в качестве аргументов за использование ДОСа пишет, что для некоторых задач именно ДОС, с его однозадачностью и сравнительной «близостью» к аппаратным ресурсам, подходит наилучшим образом. Правда он (автор) использует один из свободных клонов ДОСа.


// Написан. Будет в ближайшей рассылке :)

--------------------

Читатели ждут. :)



P. S.

Жуткая здесь система комментирования и вообще отображения материала. К кому обратиться с дельным предложением?
Алексей Федорчук, Sat Oct 20 14:41:25 2007:
2 Доброжелатель
> А Vim — это же типичное дитя юникса. Труден в освоении, зато лёгок в бою.
___
Это можно сказать про все юниксовые редакторы

> Правда трудности с «Вимом», судя по всем этим жалобам пользователей, возникают прежде всего у тех, кто сильно пристрастился к «Окнам»
___
Не только. Трудности с Vim'ом возникают у старых пользователей DOS, которые привыкли к emacs-подобным кейбиндингам редакторов типа Микростара много лет назад - и на рефлекторном уровне.

> Г-н Федорчук! Убунта свежая вышла. Что же, где Ваш обычный обзор? ;)
___
Написан. Будет в ближайшей рассылке :)

Страницы комментариев: 1 :: 2 :: 3 :: следующая

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds