Подсветка Emacs: как бороться с подсветкой, испорченной необычным использованием специальных символов?

Question

Проблема:

В режимах конфигурации Emacs (например, conf-xdefaults-mode или conf-space-mode) некоторые специальные символы используются необычным образом, например, когда они определяют привязки клавиш.Это портит подсветку для остальной части буфера.

Пример:

В файле ranger rc.conf используется conf-space-mode, что значительно улучшает его читаемость.Но такие строки, как:

map #  console shell -p%space
map "<any>  tag_toggle tag=%any

портят подсветку, поскольку # обычно определяет комментарий и сопровождается font-lock-comment-face до конца строки, а " определяет начало строки исопровождается font-lock-string-face до тех пор, пока не встретится заключительная кавычка.

Экранирование этих символов не является вариантом, поскольку это не позволит им определить привязки клавиш.

Возможное решение:

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

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

Вопрос:

Как правильно обращаться с этими ситуациями?

Есть ли способ сбросить выделение в точке в буфере?или вставить символ, который будет влиять на выделение (чтобы исправить это), не затрагивая код?или есть способ «экранировать» некоторые символы только для выделения, не затрагивая код?

Answer 1

Простой способ

Вероятно, проще всего жить с этим, но держать вещи ограниченными.Здесь я взял ranger по умолчанию rc.conf и переставил некоторые из font-lock ошибок.

Давайте проигнорируем синий"карта" на данный момент.У нас есть две видимые ошибки блокировки шрифтов.map #... блокирует шрифт как комментарий, а map "... блокирует шрифт как строку до конца буфера.Первая ошибка является самоограниченной.Комментарии заканчиваются в конце строки.Вторую ошибку мы ограничиваем, добавляя комментарий.(Я не знаю, будет ли ranger принимать комментарии в середине строки, поэтому здесь я использую только комментарии в начале строки.)

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

Это то, с чем я мог бы жить, так как я не в conf-файлах весь день (в отличие отскажем, исходный код.) Было бы еще лучше, если бы наши новые «комментарии» могли быть включены в одну строку.

Трудный путь

Вы захотите использовать Emacs font-lock-add-keywords.Давайте вернемся к этому синему map на первом изображении.Он отображается синим цветом, потому что conf-space-mode считает, что строка, за которой следует любое количество пробелов, за которым следует открывающая фигурная скобка, должна быть отображена в font-lock-type-face (на самом деле регулярное выражение, которое вызывает это ^[_space__tab_]*\\(.+?\\)[_space__tab_\n]*{[^{}]*?$, где _space_ и _tab_являются реальными пробелами и символами табуляции.)

Мы можем переопределить это простым способом, оценив

(font-lock-remove-keywords
 'conf-space-mode
 '(("^\\<\\(map\\)\\>" 1 font-lock-variable-name-face)))

и перезагрузив буфер с помощью C-x C-v RET.Теперь, каждый раз, когда слово «карта» появляется в начале строки, оно отображается как font-lock-variable-name-face (желтый в нашем примере.)

. Вы можете сделать это изменение постоянным, добавив хук в файл инициализации.,

(add-hook 'conf-space-mode-hook (lambda ()
  (font-lock-remove-keywords
   nil
   '(("^\\<\\(map\\)\\>" 1 font-lock-variable-name-face)))))

Этот метод не работает для ваших комментариев (#) и строковых (' ") разделителей, так как они определены в таблице синтаксиса.Изменение синтаксической таблицы для обеспечения особых случаев, вероятно, требует больше усилий, чем стоит.