LXF78:Почему – Vim?
|
|
|
Давнее противостояние продолжается. Адвокат Vim Владимир Попов поднимается на трибуну, чтобы дать достойный ответ оппоненту...
Содержание |
€ 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 editing);
- не-программируемость;
- цена (EMACS в те времена стоил несколько сот долларов).
Иными словами: никаких особенных претензий. Доступность редактора, по мнению Джоя, была единственным основанием для его включения в качестве базового во многие UNIX-системы. Глядя из 2006-го, поневоле задумаешься: а ведь, похоже, будущие принципы Open Source «угадывались» уже в далёкие 70-е...
Так изначальная простота и доступность обеспечили распространение VI. Без сомнения, их можно занести в актив программы и сейчас. Открытость гарантировала наращиваемость (результат – почти четыре мегабайта исходных текстов VI IMproved Брэма Моолинаара (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 group).
Подобная «жёсткая» логика в применении к файлам выглядит следующим образом:
- файлы можно создавать, удалять, читать из них, писать в них;
- открытому файлу соответствует буфер;
- окно предоставляет доступ к отдельному буферу.
Разумеется, число открытых файлов (и соответствующих им буферов) ничем не ограничивается.
Разумеется, число окон ограничивается только здравым смыслом и площадью экрана.
Разумеется, число окон никак не связано с числом буферов (открытых файлов).
Разумеется, окна могут делить экран как угодно (по горизонтали, по вертикали).
Разумеется, есть множество команд, выполняющих все возможные (иногда: непонятно зачем) действия над файлами, буферами и окнами. А выбор (меню, «горячая клавиша» или командная строка) – за пользователем.
Создаётся впечатление, что авторы задумывали универсальный инструмент работы с текстом, а как именно будет применять его пользователь – предоставили решать ему самому. Всё многообразие команд не помещается ни меню, ни в набор «горячих клавиш». Можно, конечно, свести все действия к командной строке с двумя режимами: редактирования и командным. Либо – редактируем, либо – вводим команду: просто, определённо и... утомительно. Так появились дополнительные режимы. Вообще-то у 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 слишком универсален, чтобы одному человеку потребовалось «сразу всё».
