Формат Hrc изнутри

Игорь Русских [ruiv@uic.nnov.ru]ruiv@uic.nnov.ru

Итак, этой статьей я открываю цикл заметок, связанных с колорером. Многие меня ругают за то, что я довольно плохо описываю принципы работы колорера, его секреты и все остальное в документации, поставляемой с ним. Здесь я попытаюсь восполнить этот пробел и дать более подробное описание формата, которое будет не дополнением к стандартному описанию, а, думаю, даже будет его перекрывать. В случае, если вы не знакомы с форматом HRC, я советую вам обратиться сначала к стандартной документации, а потом уже понимать эту.

Один человек, помнится мне, обругал меня за то, что в ASP-подсветке плохо был виден текстовый курсор, и совсем не видны комментарии. На основе этого было дано неопровержимое доказательство того, что ASP подсветка введена на халяву только чтобы показать, что есть такое. Для того, чтобы таких мыслей не возникало, я и пишу эту статью. Более того, как раз на примере ASP синтаксиса (как, по моему мнению, наиболее сложного) я и покажу все прелести HRC и все его закоулки.

Итак, как вы уже наверное наслышаны, базовым (и оригинальным :)) понятием в HRC являются схемы (scheme). Штука это довольно простая, и в отличие от различных систем переключения контекста довольно интуитивная. Хотя, практически по всем параметрам между построением расцветки на схемах и на контекстах можно провести параллели. Ну, если давать строгое определение, то схема - это набор неделимых атрибутов расцветки (регулярных выражений, ключевых слов) применительно к однородному содержимому целевого файла.

Так, к примеру, в схеме языка C/C++ таковой является набор ключевых слов языка, регулярных выражений, описывающих однородные области (строки, числа и др.) и некоторых других атрибутов управления (блоков - blocks), которые сами схеме не принадлежат - а принадлежит схеме лишь их управляющая часть. То есть многострочный комментарий сам по себе не является атрибутом схемы (он сам вообще говоря схема), но его параметры (регулярные выражения для переключения и закрытия, цветовые данные) - атрибуты схемы языка C. Соответственно, из этого следует определение вложенных схем - схема, в которой присутствуют параметры, указывающие на переключение на другую схему. Необходимо понимать, что вложенность схем - это не реальный признак наследования - это всего лишь ссылки - на самих схемах это никак не отражается.

Теперь пошло более сложное. На переключение схем не влияет порядок их определения. И это естественно. Одна схема может вызывать из себя другую, а та в свою очередь может вызывать первую. Это нормально (на самом деле :). Из вышесказанного следуют следующие вещи:

Дополнительно к переключению схем существует возможность включить схему в другую. Это внешне схожее действие на самом деле совершенно иное. Управляется действие тэгом <Include Scheme="">. При этом указанная схема полностью включается в текущую схему (то есть подключаются ее регулярные выражения и список ключевых слов). Это в корне отличное, но также очень мощное средство. С его помощью вы можете реализовать реальное наследование схем, при этом оно же может служить и обычной макроподстановкой - с версии Colorer 2.8 это довольно часто используется. То есть схема включает в себя много маленьких стандартно определенных схем - как то: определение подсветки строк, чисел, адресов и так далее...

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

Ну теперь после разбора базовых понятий попробуем перейти к конкретному примерчику. Разбирать будем на примере общей реализации схемы ASP. Для начала опишу чего за язык такой, так как до того, как писал расцветку сам не знал :) В обсчем основной смысл в том, что в обычный HTML вставляются дополнительные блоки, выделенные символами <% и %>. Внутри этих блоков находится либо код Ява-скрипт, либо Бейсик. Собственно, вот и все из чего она состоит - своих собственных определений у ASP нет. Итак,

Это общая схема. На самом деле все сложнее. Дело в том, что в блоки <% и %> могут быть заключены или VB или JS коды - это определяется по первой строке. Еще одна сложность состоит в том, что ASP вставки могут появляться в любых местах Html-кода, включая строки в параметрах и даже в скриптах. Из-за всего этого создается довольно развитая структура схем. Размер всех схем не большой, так как практически все они только лишь наследуются от базовых уже определенных схем Html, VBScript, JScript. Итак, структура взаимодействий состоит из схем:

Совершенно аналогичные структуры и схемы определяются для набора VB-скриптов, после чего VB-вариант становится по умолчанию, а вариант с явой скриптом подключается следующим образом:
<Switch Match='/language\s*=.*j(ava)?script/i' Scheme="AspJS">

Ну, вот чего я хотел разъяснить вам по схемам - на самом деле все проще простого. Главное захотеть понять все это.

Еще одна вещь, которую я хочу обсудить здесь - это использование цветов в настройках Hrc. Сейчас работает возможно не всем ясная структура, при которой происходит замена цветов фона - если в указанном цвете (в любом регулярном выражении или ключевом слове) цвет фона равен нулю, то он считается равным не черному цвету, а текущему цвету фона. Это необходимо, так как большинство цветов задаются с цветом фона по умолчанию - а он естественно заранее неизвестен. В случае же, если необходим именно черный цвет - надо в цвете фона указать именно текущий цвет фона.

То есть к примеру Color="#14" определит красное на черном, если текущий цвет фона - синий. В ином случае это будет красное на синем. Хочу также подчеркнуть, что текущий цвет фона это не только цвет фона FAR по умолчанию, или цвет, задаваемый параметром Color тэга <Files ...> - это и фоновый цвет любого переключения схем. То есть цвет фона изменяется при любом изменении контекста схемы (хотя в большинстве схем цвет тот же, что и в родительской). В связи с такой структурой возможны некоторые побочные эффекты. Так, если схема многократно включается сама в себя и при этом имеет отличающийся от дефолтового цвет фона, у нее начнется чередование цвета фона с черным - что совсем не красиво. Это можно довольно просто обойти путем определения дополнительной схемы, которая наследуется от первой, и включает тот самый блок (но с обычным цветом фона), которым она инициализируется (то есть который порождает переключение на нее).

Вы можете задать вполне резонный вопрос: "на кой черт так извращаться, если все цвета определяются через константы d<name>, между которыми и надо устанавливать соответствия?". Собственно это почти так. Можете считать, что эта структура осталась атавизмом от старых версий, в которых цвета определялись от балды. Возможно, в следующих версиях(если они будут :-), я перекрою это, и сделаю структуру цветов более гибкой - что, к сожалению, вызовет несовместимость версий колорера на уровне программного интерфейса - но это уже совсем другая статья :)


 
14.12.1999
наверх