ahk.coder: forcing an expression or forcing a variable in an attribute breaks the command's highlighting at all for too specific rules

Я думал, что я делаю правильно, когда для некоторых атрибутов команд делаю очень подробные правила перечисляя там все возможные атрибуты. Но, кажется, это всё придётся отменить, т.к. несмотря на то, что в документации у тех атрибутов не стоит пометка, что можно в них использовать выражения - можно всегда форсировать выражение или переменную, а в таком случае строка уже не подпадёт под правило и не раскрасится как надо. Пример правила (строка 213):

0   "^\s*(?:\}\s*)*?(?:(Else)(?:\s*,\s*|\s+|\s*\{\s*)|(.+(?=::))::)?(?:(Try)(?:\s*,\s*|\s+|\s*\{\s*))?\s*(#InputLevel)(?:(?:\s*,\s*|\s+)(100|[1-9]\d|\d)?)?\s*?((?<=\s);.*)?$" "\1=(4,${IF},0) \2=(4,${STR},0) \3=(2,${OP},0) \4=(2,${AREA},0) \5=(0,${NUM},0) \6=(3,${COMM},0)"    ; \5=${LEVEL}

Пример обычного использования:

#InputLevel, 95

Пример валидного употребления этой команды, но не подпадающее под правило:

var := 20
#InputLevel, %var%

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

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

Форсирование переменных идёт через "%имя_переменной%" - добавить этот случай употребления легко. Форсирование выражения идёт через "% " в начале атрибута. Если выражение и содержит не экранированные запятые, то они обычно подпадают под шаблон:

Command, attr1, …, attrN-2, attrN-1, % possibleTextPresent(…here, may, be, commas and (more, subexpressions)), attrN+1, attrN+2, …, attrLast

По идее, должна произойти какая-то подобная мутация правил:

(100|[1-9]\d|\d)?
-> (добавление поддержки форсирования переменных)
(100|[1-9]\d|\d|%[\w#@\.]+%)?
-> (поддержка форсирования выражений)
(100|[1-9]\d|\d|%[\w#@\.]+%|%\s+.*?\(?.*\)?)?

Только, во-первых, я не проверял жизнеспособность этого правила, а во-вторых, даже если оно будет правильно работать - его раскраска будет туповатой: всё выражение целиком будет подкрашено одним цветом, а это не правильно, т.к. выражение может помимо отправки команде какого-то атрибута выполнять и другие действия (практически любые: вызов функций, объявление переменных и присвоение им значений), а чтобы всё это более или менее правильно подкрасилось - боюсь, что надо снова просить тов. Instructor'а вносить изменения в работу coder-плагина.

Просить надо о добавлении каскадного применения правил или как минимум о том, что если есть 2 правила подсветки

0   `(bbb)` `\1=(0,#00ff00,0)`
0   `(aaa).*(aaa)` `\1=(0,#ff0000,0) \2=(0,#ff0000,0)`

то строка aaabbbaaa раскрашивалась бы не так, как она раскрашивается сейчас (), а чтобы bbb в ней раскрашивалось верхним правилом.

Lenchik / Akelpad-syntax-highlighting

ahk.coder: forcing an expression or forcing a variable in an attribute breaks the command's highlighting at all for too specific rules #16