Humane VimScript: Ініціалізація редактора

Введення
При кожному запуску редактора Vim, їм виконується процес ініціалізації, що забезпечує зручний інтерфейс для користувача. На перший погляд модель ініціалізації може здатися простий і зрозуміло, але це далеко не так.
У цій статті я пропоную вам ознайомитися з процесом ініціалізації редактора Vim. Дану тему я вважаю однією з найбільш складних у ході вивчення редактора, від чого матеріал, викладений мною, може бути дуже корисний як новачкам, початківцям цей тернистий шлях, так і досвідченим користувачам і розробникам.
Складність цієї теми обумовлена нетривіальною моделлю завантаження скриптів редактора, а так само кількістю груп, на які ці скрипти діляться. Запам'ятати порядок ініціалізації редактора досить складно, але це дуже важливо для написання власних плагінів для нього.
Ініціалізація редактора
— Хто?
Для початку розглянемо, хто відповідає за завантаження скриптів і, з їх допомогою, ініціалізацію редактора. Таких точок завантаження в Vim всього дві:
  • Редактор — за пошук і завантаження скриптів відповідає логіка, "вшита" безпосередньо в код редактора
  • Скрипти — за пошук і завантаження скриптів відповідає логіка інших скриптів
Щоб вам стало зрозуміліше, погляньте на файл
$VIM/vimrc
. Цей скрипт завантажується (і виконується) логікою самого редактора. З іншого боку сам скрипт
$VIM/vimrc
, як правило, включає логіку завантаження інших скриптів.
Важливою відмінністю скриптів, що завантажуються редактором, від інших є те, що перші можуть бути відключені (або підключені) тільки з використанням опцій запуску Vim, таких як
u
(вказує кореневої користувальницький скрипт) або
--noplugin
(забороняє завантаження плагінів). У свою чергу завантажені скрипти можуть керувати ініціалізацією за допомогою деякої логіки, програмованої розробником.
— Коли?
Для зручності та підвищення безпеки процесу ініціалізації редактора, механізм розбитий на два основних етапи:
  • Загальносистемний — завантаження на цьому етапі скрипти впливають на роботу всіх користувачів комп'ютера
  • Інтерфейс — завантаження на цьому етапі скрипти впливають на роботу тільки поточного користувача комп'ютера
З допомогою опції
exrc
може бути підключено ще один етап:
  • Проектний — завантаження на цьому етапі скрипти впливають на роботу тільки поточного сеансу редактора
насправді ви можете додати власні етапи до вже наявних, важливо лише дотримуватися порядок завантаження і сфера відповідальності кожного етапу.
Порядок завантаження скриптів не строгий. Він визначається вмістом опції
runtimepath
, в якій перераховуються адреси каталогів, що зберігають файли ініціалізації в тому порядку, в якому вони повинні бути завантажені.
На жаль це найбільш непередбачувана частина механізму ініціалізації редактора. Справа в тому, що тут застосовується зовсім не той порядок завантаження, який міг би здатися вам найбільш очевидним. Зокрема без належної налаштування, спочатку буде виконуватися ініціалізація користувальницьких скриптів, а тільки потім загальносистемних. У цьому можна переконатися глянувши на вміст опції
runtimepath
, у мене воно таке (без установки):
runtimepath=~/.vim,/usr/share/vim/vimfiles,/usr/share/vim/vim74,/usr/share/vim/vimfiles/after,~/.vim/after
.
Як видно, першими в черзі ініціалізації стоять користувальницькі скрипти, а це значить, що вони будуть заміщені загальносистемними при старті редактора. Несподіване, чи не правда? Я досі сушу голову над причиною, що спонукала авторів застосувати саме такий порядок ініціалізації.
Що?
Сценарії ініціалізації редактора згруповані таким чином, в залежності від цілей:
  • Базові (.vimrc) — скрипти, які відповідають за загальну инциализацию редактора
  • Контексто-визначальні (ftdetect/) — скрипти, які відповідають за виявлення контексту (типу редагованого файлу)
  • Контексто-залежні (ftplugin/) — скрипти, инициализирующие редактор залежно від контексту
  • Колірні схеми (colors/) — правила підсвічування інтерфейсу
  • Скрипти підтримки компіляторів (compiler/) — скрипти для використання компіляторів
  • Довідники (doc/) — документація
  • Файли розкладки клавіатури (keymap/) — маппінг розкладки клавіатури
  • Конфігурація меню (menu.vim) — файл конфігурації меню
  • Переклади меню (lang/) — файл локалізації меню
  • Підсвічування синтаксису (syntax/) — конфігурація підсвічування синтаксису мови
  • Плагінів (plugin/) — скрипти ініціалізації плагінів
  • Сценарії створення відступів (indent/) — конфігурація відступів
  • Допоміжні сценарії для друку (print/) — конфігурація системи друку
  • Файли підручника (tutor/) файли підручника
Така різноманітність використовуваних для скриптів ініціалізації обумовлено функціональними можливостями редактора. Звичайно, ніхто не забороняє використовувати єдиний скрипт ініціалізації для конфігурування всіх механізмів редактора (на приклад у файлі
~/.vimrc
), але я так робити не рекомендую (файл швидко пухне, чи знаєте).
Контекстно-залежні скрипти
Про контексті скриптів слід поговорити окремо. На відміну від деяких редакторів, Vim не прив'язаний до конкретного синтаксису або мови. З його допомогою можна однаково просто писати книгу, редагувати вихідні коди програми або працювати з двійковими (hex) файлами. Досягається це завдяки можливості локалізувати конфігурацію конкретним буфером редактора. Іншими словами, ви можете сконфігурувати одне вікно редактора з використанням першого скрипта, а друге — з використанням другого, в залежності від типу редагованих в ньому файлів. Тип файлів, в даному випадку, я і називаю — контекстом.
Як вам (можливо) відомо, Vim має зворотну сумісність з редактором Vi, який, у свою чергу, створювався з урахуванням особливостей Unix-подібних систем. З точки зору контексту, це означає, що тип редагованого файлу не завжди можна визначити по його імені (розширення), часто для цих цілей редакторові необхідно працювати з вмістом редагованого файлу. Для цих цілей застосовуються контексто-визначають скрипти, які розташовуються в каталозі
ftdetect/
, а так само скрипт
filetype.vim
.
Після того, як визначений контекст, для редагованого файлу викликаються скрипти каталогу
ftplugin/
. Їх конфігурації повинні (але це ніяк не обмежується) застосовуватися тільки до поточного буферу.
Конфігурація механізму ініціалізації
Ви можете самостійно налаштувати механізм ініціалізації редактора, але робити це треба вкрай обережно. Я не рекомендую вам змінювати вміст загальносистемних скриптів ініціалізації, так як це може привести до несподіваного поведінки редактора.
Перед тим, як приступити до конфігурації механізму ініціалізації, відкрийте ваш редактор Vim і виконайте команду
:scriptnames
, ви побачите список завантажених при старті редактора файлів. Це дуже корисна інформація, до якої ви будете звертатися постійно, щоб дізнатися, чому той чи інший скрипт перестав працювати. Так само за допомогою цього списку легко простежити порядок ініціалізації редактора.
І так, як же можна сконфігурувати механізм ініціалізації? В першу чергу виконайте команду
set runtimepath?
і погляньте на вміст опції
runtimepath
. Ви можете змінити порядок завантаження ваших файлів ініціалізації або підключити нові каталоги з її допомогою. Для цього відкрийте файл
~/.vimrc
і додайте в нього наступний запис:
set runtimepath=каталоги розділені комою
. При повторному старті редактора вже буде застосовано вказаний вами порядок завантаження. Врахуйте лише те, що до моменту завантаження вашого файлу
~/.vimrc
, редактором буде застосовуватися заданий у загальносистемних файлах конфігурації порядок ініціалізації.
Іншим способом конфігурування механізму ініціалізації є підключення додаткового, проектного етапу ініціалізації. Для цього додайте у ваш файл
~/.vimrc
наступний рядок:
exrc
. Тепер при старті редактора, буде виконуватися не тільки власний файл ініціалізації
~/.vimrc
, але файл з тим же ім'ям в поточному каталозі (
./.vimrc
). Він може застосовуватися для конфігурування редактора під кожен конкретний проект. Більше того, ніщо не заважає вам додати в проекті каталог
.vim
і запис у файл
./.vimrc
:
set runtimepath+=./.vim
. Після цього ваш проектний каталог
.vim
стане аналогічний користувача каталогу
~/.vim
, що полегшить структурування ваших конфігураційних файлів проекту.
Поки всі
Так, стаття досить складна, не рясніє прикладами і частково повторює документацію. Справа в тому, що це вступ до іншої, більш цікавої теми, яку я постараюся висвітлити в майбутньому, але зробити це без цих знань буде занадто складно.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.