Общий вопрос про недавнее изменение в Coder плагине

Не так давно Instructor сделал крупное изменение в работе coder плагина, добавив в него поддержку иерархии правил. Кто-нибудь разобрался уже как оно работает? В частности при связывании QuotesRE правила с другим QuotesRE правилом.

В issue #26, @Skif-off упомянул про проблему с окраской многострочных команд (Splitting a Long Line into a Series of Shorter Ones; concatenate, script lines):

И вот такой кусок кода

  ,"\\Оформление и персонализация\Экран|shell:::{26EE0668-A00A-44D7-9371-BEB064C98683}\1\::{C555438B-3C23-4769-A71F-B6D3D9B6053A}"
  ,"\\Оформление и персонализация\Шрифты|control fonts"
  ,"Шифрование диска BitLocker\Шифрование диска BitLocker|shell:::{26EE0668-A00A-44D7-9371-BEB064C98683}\0\::{D9EF8727-CAC2-4e60-809E-86F80A666C91}"
  ,"Шрифты\Шрифты|control fonts"
  ,"\\Специальные возможности\Центр специальных возможностей|" EASE_OF_ACCESS_CENTER ""
  ,"\\Специальные возможности\Распознавание речи|" SPEECH_RECOGNITION ""

С многострочным кодом проблему можно решить только радикально переписав все QuotesRE правила, я пока не представляю как и пока даже не уверен, что это в принципе возможно при нынешнем coder'е.

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

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

По хорошему, правильная подсветка должна быть описана начиная с атомарных элементов кода: чисел, строк и переменных + операторов. Казалось бы простая вещь, но сложность тут заключается в том, что это всё должно быть описано без построчной привязки, т.к. строка (string) может располагаться на нескольких строках (lines), и это надо учесть в правиле.

Затем, должны быть описаны более комплексные сущности, вроде выражений, которые могут состоять из произвольного количества вышеназванных атомарных единиц + символов referencing'а и dereferencing'а. Плюс, тут уже должны быть некоторые правила для проверки местоположения операторов, т.к. 2 оператора идущих подряд - это недопустимо.

И вот только тогда уже можно будет создавать правила для раскраски аргументов у команд.

У меня пока не было времени разобраться в том как работает иерархичность правил, может кто-то из вас уже разобрался?

И вот такой кусок кода

Возможно ли просто добавить правило для содержимого кавычек ""? Или основательно поломает задуманное/реализованное?

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

,"Шифрование диска BitLocker\Шифрование диска BitLocker|shell:::{26EE0668-A00A-44D7-9371-BEB064C98683}\0\::{D9EF8727-CAC2-4e60-809E-86F80A666C91}"

подсветка распознала этот пример как hotkey правилом (на строке 424):

0   "^\s*+((?:[^;]|(?<=`);)+)\s*+::" `\1=(4,${STR},0)`  0   0

и формально она права :smiley:

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

Да, получается - просто разбито для удобства, там массив: здесь или здесь

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

var_name = [ ]

сделать родительским, а уже внутри разобраться с кавычками? Так же, так понимаю, можно подтянуть дочерними правила в Quotes и QuotesRE.

P.S. Не знаю, как быть, как-то не очень нравится ломка в неожиданных местах, у себя пока откатил на 2013.10.10 05:15, что-то поправлял, секцию Blocks целиком взял из теперь предпоследней версии.

У меня пока не было времени разобраться в том как работает иерархичность правил, может кто-то из вас уже разобрался?

Я тут в недавнем коммите исправил проблему, когда запятые внутри literal string в аргументе ломали подсветку т.к. распознавались как разделители между аргументами. Благодаря иерархичности правил удалось приделать и правильную раскраску literal string'ов (одинаковая везде, не пришлось городить огород в QuotesRE правилах для команд). Первый шаг в сторону раскраски кода на основе атомарных элементов.

Lenchik / Akelpad-syntax-highlighting

Общий вопрос про недавнее изменение в Coder плагине #28