Проверка орфографии в редакторе понимает технические термины через свой словарь

Опечатка в документации к проекту обнаруживается обычно в самый неудачный момент - когда её уже прочитали другие. Писать README, описания коммитов, технические заметки прямо в редакторе vim удобно, но встроенный редактор не подсвечивает ошибки, как привычный текстовый процессор. Между тем такая проверка в редакторе есть, причём встроенная, без всяких дополнений. Её главная сложность для технического текста в другом: словарь не знает терминов вроде названий форматов, библиотек и команд, и подчёркивает их как ошибки, утопая полезные подсказки в потоке ложных срабатываний.

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

Включение проверки и выбор языка

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

:set spell                      включить проверку во всех окнах
:setlocal spell spelllang=en_us включить только в текущем буфере, язык США

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

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

:set nospell      выключить проверку и убрать подсветку

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

Навигация по ошибкам и получение подсказок

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

]s     перейти к следующему слову с ошибкой
[s     перейти к предыдущему слову с ошибкой

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

z=     показать список вариантов исправления для слова под курсором

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

Пользовательский словарь учит редактор техническим терминам

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

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

zg     добавить слово под курсором в словарь как правильное

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

Бывает и обратное: редактор счёл слово верным, а оно ошибочно. Тогда его помечают как неправильное командой пометки. А если добавление или пометка сделаны по ошибке, есть парные команды отмены, убирающие слово из пользовательского словаря.

zw     пометить слово под курсором как ошибочное
zug    отменить добавление слова (убрать из словаря хороших)
zuw    отменить пометку слова как ошибочного

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

Автоматическое включение для нужных типов файлов

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

" включать проверку для документов и описаний коммитов
autocmd FileType markdown setlocal spell
autocmd FileType gitcommit setlocal spell

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

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

Проектный словарь и автодополнение терминами

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

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

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

" подключить словарь проверки к автодополнению
set complete+=kspell

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

Что складывается в практику

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

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

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