Coder plugin (3)

Instructor · Post by **Instructor** » Sun Jun 05, 2016 10:27 am

Skif_off
В vbs.coder подобный синтаксис.

Folds:
;===========================================================================================
;Flags  Font    Color   Color   Fold        Fold           Deli         Parent  Rule    Rule
;       style   text    bkgrnd  start       end            miters       ID      ID      file
;===========================================================================================
;--if...else...end--
;40=8+32
40	0	0	0	"if"        "end"          " 	"	0	0
;424=8+32+128+256
424	0	0	0	"if"        "elsif"        " 	"	0	0
;424=8+32+128+256
424	0	0	0	"if"        "else"         " 	"	0	0
;40=8+32
40	0	0	0	"elsif"     "end"          " 	"	0	0
;424=8+32+128+256
424	0	0	0	"elsif"     "elsif"        " 	"	0	0
;424=8+32+128+256
424	0	0	0	"elsif"     "else"         " 	"	0	0
;40=8+32
40	0	0	0	"else"      "end"          " 	"	0	0

Skif_off · Post by **Skif_off** » Sun Jun 05, 2016 12:18 pm

Instructor
Пробовал с 1+4+8+32+128+256, складывается впечатление, что флаг 256 не срабытывает, покручу ещё.

Skif_off · Post by **Skif_off** » Sun Jun 05, 2016 6:04 pm

Кажется, начинаю соображать, подзабывать стал: флаг 128 нельзя использовать везде и всегда, иначе на Fold end повиснут все, кому не лень, а я его прицепом с 256...

Ломается в

Code: Select all

if some_condition
  10.times do
    # некоторый код в несколько строк
  end
end

которое толком не отловишь по do, ибо можно и так:

Code: Select all

names.each do |name|
  puts name
end

из-за "лишних" end.

Вообще, как заставить использовать один уровень, а не цепляться к первому встречному Fold end? Флаг 256?

Drugmix · Post by **Drugmix** » Mon Jun 06, 2016 12:46 am

Skif_off wrote:Drugmix
А что сейчас работает непредсказуемо?

Rule ID/Parent ID ни в коей мере не помогают "каскадному применению правил"?

Да много чего, но что бы что-то конкретное предъявлять - хотелось бы сначала увидеть документацию и примеры применения.
Вот где взять документацию по составлению .coder файлов вообще? Где рассказано какие секции есть в .coder файлах, как их оформлять, как их наполнять правилами, какие флага чему соответствуют в каждой секции?
В Coder-[Rus/Eng].txt про составление .coder файлов говорится только в конце в секциях

*** Описание иерархии, применяющейся в *.coder файлах ***

и

*** Описание некоторых переменных, применяющихся в темах Coder::Settings ***

Если с переменными ещё понятно, то вот читая про описание иерархии - я каждый раз ловлю себя на том, что хоть и перечитываю текст по пятому разу, но яснее от этого ничего не становится с этими Rule ID/Parent ID.
Ладно я тупой и не понимаю, но где примеры применения?
Хоть один из кодеров содержит связки между парами QuotesRE правил?

Метод проб каждый раз приводит или ни к чему, или ко взрыву:
беру что-то просто из существующего ahk.coder и начинаю тестировать:

Code: Select all

0	`(")((?:[^"]|"")*+)(")` `\1=(0,#ffff00,0) \2=(0,#00ffff,0) \3=(0,#ffff00,0)`	-3	0

работает. Хочу к нему приделать дочернее правило и потому присваиваю Rule ID = 1:

Code: Select all

0	`(")((?:[^"]|"")*+)(")` `\1=(0,#ff0,0) \2=(0,#0ff,0) \3=(0,#ff0,0)`	-3	1

И оно на

""

Пытаюсь разобраться - баг это или нет, заново читаю документацию: в ней говорится, что

- Если родитель (Parent ID) равен -3:
- Внутри родителя с идентификатором (Rule ID) == 0, см. обработку родителя (Parent ID) равного 0.
- Внутри родителя с идентификатором (Rule ID) > 0, правило обрабатывается.

Но у нас одно правило, что в таком случае? Не ясно.
Но допустим, что ошибка как раз в том, что у нас одно правило. Чтобы исправить эту ошибку - добавим второе правило

Code: Select all

0	`^\s*(Command)\s*,\s*(.*)$`	`\1=(0,${OP},0) \2=(0,${STR},0)`	0 0

ну да ладно, что оно акелпад снова крэшится на

""

но на

Command, "test"

оно же должно наконец сработать? Я не знаю, ведь в документации говорится

- Если родитель (Parent ID) равен -3:
- Внутри родителя с идентификатором (Rule ID) == 0, см. обработку родителя (Parent ID) равного 0.

и чёрт его знает куда смотреть, ведь в документации про иерархию идёт какая-то путаница между Parent ID (значением, указываемым в дочерних правилах) и родительским правилом (правилом, с каким-то Rule ID, которое у какого-то другого правила указано как Parent ID).

Чёрт с ней с путаницей в документации, вернёмся к опытам. Может у родительского правила всё же нельзя выставлять Rule ID равный 0?
Попробуем выставить ему Rule ID = 2 и... снова крэш на

Command, "test"

Что уже похоже на баг, ведь в документации сказано

- Если родитель (Parent ID) равен -3:
- Внутри родителя с идентификатором (Rule ID) > 0, правило обрабатывается.

Хотя последний процитированный кусок документации не всегда приводит к крэшу, если у дочернего правила назначить rule id == 0, а у родительского оставить любым положительным - краша нет.

p.s.:
Опытным путём выяснено, что связки всё же работают в случаях
- если втупую указывать parent id == rule id родительского правила;
- если выставить дочернему правилу parent id == -2 или -3 (и rule id должен обязательно быть нулём), а родительскому правилу выставить положительное значение rule id.

p.p.s.: всё же общаться о багах было бы удобней в рамках багтреккера.
p.p.p.s.: coder - наверно самый сложный из плагинов akelpad'а и основной его функционал всё же в работе подсветки синтаксиса по .coder файлам и это очень плохо, что как раз составление .coder файлов нигде толком не описано.

YuS · Post by **YuS** » Mon Jun 06, 2016 9:06 am

Drugmix wrote: Да много чего, но что бы что-то конкретное предъявлять - хотелось бы сначала увидеть документацию и примеры применения.

У AP традиционно не существует подробной документации. Всё познаётся чтением специальных файлов помощи, общей html-документации, изучением примеров и конечно же, эмпирическим путём... да, ещё, естественно, подсказками на форуме.

Drugmix wrote: Вот где взять документацию по составлению .coder файлов вообще? Где рассказано какие секции есть в .coder файлах, как их оформлять, как их наполнять правилами, какие флага чему соответствуют в каждой секции?

Coder-Rus.txt и сами файлы .coder, в которых описаны флаги для секций... рабочие примеры, в принципе, достаточно наглядны ведь.

Drugmix wrote: Хоть один из кодеров содержит связки между парами QuotesRE правил?

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

Drugmix wrote: беру что-то просто из существующего ahk.coder и начинаю тестировать:
Code: Select all
0	`(")((?:[^"]|"")*+)(")` `\1=(0,#ffff00,0) \2=(0,#00ffff,0) \3=(0,#ffff00,0)`	-3	0
работает. Хочу к нему приделать дочернее правило и потому присваиваю Rule ID = 1:
Code: Select all
0	`(")((?:[^"]|"")*+)(")` `\1=(0,#ff0,0) \2=(0,#0ff,0) \3=(0,#ff0,0)`	-3	1
И оно
(причём как крэшится! Аж курсор начинает лагать через некоторое время, если вовремя процесс акелпада не убить)
на
""

Здесь подробности нужны... крашится сразу после присвоения RuleID, без создания дочернего правила или оно таки есть? Учитывается ли то, что шаблоны из QuotesRE однострочны по своей природе? И что именно будет искать дочерний шаблон из "ничего", т.е. в ""?

Drugmix wrote: Пытаюсь разобраться - баг это или нет, заново читаю документацию: в ней говорится, что
- Если родитель (Parent ID) равен -3:
- Внутри родителя с идентификатором (Rule ID) == 0, см. обработку родителя (Parent ID) равного 0.
- Внутри родителя с идентификатором (Rule ID) > 0, правило обрабатывается.
Но у нас одно правило, что в таком случае? Не ясно.

Исходя из вышесказанного, понимаю, что дочернего правила не существует. Правильно? Если да и крашится сразу после присвоения RuleID=1, тогда где-то баг засел.

Drugmix wrote: Но допустим, что ошибка как раз в том, что у нас одно правило. Чтобы исправить эту ошибку - добавим второе правило
Code: Select all
0	`^\s*(Command)\s*,\s*(.*)$`	`\1=(0,${OP},0) \2=(0,${STR},0)`	0 0
ну да ладно, что оно акелпад снова крэшится на
""
но на
Command, "test"
оно же должно наконец сработать? Я не знаю, ведь в документации говорится
- Если родитель (Parent ID) равен -3:
- Внутри родителя с идентификатором (Rule ID) == 0, см. обработку родителя (Parent ID) равного 0.
и чёрт его знает куда смотреть, ведь в документации про иерархию идёт какая-то путаница между Parent ID (значением, указываемым в дочерних правилах) и родительским правилом (правилом, с каким-то Rule ID, которое у какого-то другого правила указано как Parent ID).

Да нормально там описано. А если последовательно, то вот это вот, Ваше второе правило будет являться родителем для первого, причем неважно, что у первого правила в RuleID=0 или RuleID=1... Вы именно это задумывали? Может быть в этом у Вас путаница возникает?
В столбце ParentID пишется идентификатор родителя, в котором будет работать редактируемое правило, т.е. оно является дочерним.
А в столбце RuleID указываем идентификатор родителя, т.е. это правило будет родителем для других правил с таким же ParentID (естественно, учитывая дополнительные условия иерархии: типа оформленный или неоформленный диапазон, какая секция и для какой может быть родителем и т.п.)

Drugmix wrote: Чёрт с ней с путаницей в документации, вернёмся к опытам. Может у родительского правила всё же нельзя выставлять Rule ID равный 0?

Я бы сказал так, что у родительского правила нельзя выставлять ParentID<1, если не требуется, чтобы оно было дочерним для какого-либо правила с RuleID равном 0.

Drugmix wrote: Хотя последний процитированный кусок документации не всегда приводит к крэшу, если у дочернего правила назначить rule id == 0, а у родительского оставить любым положительным - краша нет.

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

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

Drugmix · Post by **Drugmix** » Mon Jun 06, 2016 12:14 pm

YuS wrote:У AP традиционно не существует подробной документации. Всё познаётся чтением специальных файлов помощи, общей html-документации, изучением примеров и конечно же, эмпирическим путём... да, ещё, естественно, подсказками на форуме.

Да я в курсе, просто хотел ещё раз подчеркнуть, что это плохая традиция, её бы изменить...

YuS wrote:Coder-Rus.txt и сами файлы .coder, в которых описаны флаги для секций... рабочие примеры, в принципе, достаточно наглядны ведь.

В дефолтных .coder файлах возможности coder используются по минимуму, где сложные QuotesRE правила? Где связки пар QuotesRE правил?

YuS wrote:Конкретно с парами правил, именно из QuotesRE, может быть и нет, но там и нет принципиальной разницы, надо только последовательно и неспешно читать иерархию.

Вот потому, что их никто не использует - никто и не видит проблему/неудобство, которое вижу я: если в родительском правиле есть несколько групп подсветки, то подключить дочернее правило только к одной из групп - нельзя, т.к. существующий механизм подключает дочернее правило ко всему родительскому правилу (т.е. дочернее правило сработает в любой группе подсветки из родительского правила и даже вне групп подсветки, что чревато нежелательными срабатываниями).

YuS wrote:Здесь подробности нужны... крашится сразу после присвоения RuleID, без создания дочернего правила или оно таки есть? Учитывается ли то, что шаблоны из QuotesRE однострочны по своей природе?

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

YuS wrote:И что именно будет искать дочерний шаблон из "ничего", т.е. в ""?

Сами кавычки и подсветит, вторая группа подсветки состоит из 0 символов, но т.к. в regexp'е у нас там использовалась звёздочка, то это гарантирует срабатывания правила и на

""

и на

"string"

если так понятней про что я (на таком примере тоже падает, само собой).

YuS wrote:Исходя из вышесказанного, понимаю, что дочернего правила не существует. Правильно? Если да и крашится сразу после присвоения RuleID=1, тогда где-то баг засел.

Мне тоже кажется, что баг. Но именно кажется, т.к. я не могу определить противоречит ли это падение документации или нет.
С другой стороны - падения вообще не должны происходить даже в случае ошибок в правилах подсветки: пускай хоть ошибку выдаст, но не падает.
Мне вот интересно, Instructor прочитает наши волны текста или может упустить упоминание об этих падениях?
Был бы баг-треккер (как я ранее уже неоднократно предлагал и даже просил сделать) - такой бы проблемы не было.

YuS wrote:Да нормально там описано. А если последовательно, то вот это вот, Ваше второе правило будет являться родителем для первого, причем неважно, что у первого правила в RuleID=0 или RuleID=1... Вы именно это задумывали? Может быть в этом у Вас путаница возникает?
В столбце ParentID пишется идентификатор родителя, в котором будет работать редактируемое правило, т.е. оно является дочерним.
А в столбце RuleID указываем идентификатор родителя, т.е. это правило будет родителем для других правил с таким же ParentID (естественно, учитывая дополнительные условия иерархии: типа оформленный или неоформленный диапазон, какая секция и для какой может быть родителем и т.п.)

Нет, с пониманием отношения родительских и дочерних правил в описанном вами контексте - у меня проблем нет.
Путаница там в том, что слово "родитель" используется в двух конструкциях:

Если родитель (Parent ID) равен -3

и

Внутри родителя с идентификатором (Rule ID) == 0

а фраза

см. обработку родителя (Parent ID) равного 0.

вносит дополнительную неясность, ведь про обработку правил с Parent ID == 0 есть только такой блок

- Если родитель (Parent ID) равен 0 (по умолчанию):
- Внутри не оформленного диапазона ("Quotes:", "QuotesRE:"), правило обрабатывается.
- Внутри оформленного диапазона ("Quotes:", "QuotesRE:"), правило игнорируется.
- Внутри не оформленного блока ("Folds:"), правило обрабатывается.
- Внутри оформленного блока ("Folds:"), правило из "Folds:" обрабатывается, из остальных секций игнорируется.

Что такое "оформленный диапазон" и "не оформленный диапазон"?
И снова няня

YuS wrote:Я бы сказал так, что у родительского правила нельзя выставлять ParentID<1, если не требуется, чтобы оно было дочерним для какого-либо правила с RuleID равном 0.

А если требуется - то можно? Или такое не поддерживается?

YuS wrote:На самом деле для родителя пофиг, что указано у дочернего правила в RuleID, дочернее правило будет считаться дочерним, как минимум, если у него ParentID совпадает с RuleID родителя или ParentID равно, либо меньше нуля, но с учётом доп.условий.

Ну вот а опыт доказывает, что не пофигу: в одном случае падение, а в другом - его нет.

YuS wrote:Начните разбор от простого к сложному=> Т.е. удалите абсолютно все правила, оставьте для тестов всего два и экспериментируйте с ними, чтобы не запутаться окончательно...

Так я так и делаю, но всё равно либо натыкаюсь на падения, либо на странную работу правил, вот свежий пример:

Code: Select all

0	`^\s*(Command)\s*,\s*(.*)$`	`\1=(0,${OP},0) \2=(0,${AREA},0)`	0 1
0	`(")((?:[^"]|"")++)(")` `\1=(0,#f00,0) \2=(0,${STR},0) \3=(0,#f00,0)`	1	2
0	`(")"`	`\1=(0,${DEL2},0)`	2	0

Вроде работает норм, но стоит захотеть в правиле подсветки удвоенных кавычек внутри строки сделать подсветку не левой, а правой кавычки, как всё немножко ломается:

Code: Select all

0	`^\s*(Command)\s*,\s*(.*)$`	`\1=(0,${OP},0) \2=(0,${AREA},0)`	0 1
0	`(")((?:[^"]|"")++)(")` `\1=(0,#f00,0) \2=(0,${STR},0) \3=(0,#f00,0)`	1	2
0	`"(")`	`\1=(0,${DEL2},0)`	2	0

Почему вдруг изменения в правиле подсвечивающем только двойные кавычки повлияло на подсветку остального текста, подсвечиваемого другим правилом?

Я уж молчу про то, что даже в первом варианте, где всё более или менее подсвечивается - нет возможности сделать так, чтобы цвет правой кавычки не слетал полностью, а происходил бы "fallback" к правилу выше, т.е. чтобы в этом случае цвет у неё был бы равен ${STR}.

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

Но это же ведь даст желаемый результат только в этом конкретном случае, а не во всех: а что если у этого дочернего правила несколько родительских и в одном кавычка должна подсветиться как ${STR}, а в другом - иначе? Мне что, дублировать правила тогда?

Эх, было бы каскадное применение правил - не было бы никаких проблем.

Drugmix · Post by **Drugmix** » Tue Jun 07, 2016 11:05 pm

Можно ли в css.coder составить правила так, чтобы работало сворачивание блоков между { и } в таком примере:

/* { Начало сворачиваемого блока */
#code { color: red ; }
/* } Конец сворачиваемого блока */

И чтобы при этом отдельно ото всего работали и нынешние правила сворачивания блоков (т.е. между /* и */, и между { и })?

Если просто у

Code: Select all

513	3	${COMM}	0	"/*"    "*/"   ""       0	0

выставить флаг не 513, а 1 (или 0, т.к. регистрозависимость в этом правиле не имеет смысла), то акелпад в примере выше не находит конца блока для свёртки:

Мне не обязательно именно правило для { ... }, подойдёт и [ ... ] или ( ... ), проблема не в этом.

Skif_off · Post by **Skif_off** » Wed Jun 08, 2016 8:33 am

Drugmix wrote:или 0, т.к. регистрозависимость в этом правиле не имеет смысла

Имеет, в любом правиле и секции.

И вы так и не прояснили, что подразумевается под "каскадным применением правил"? Разве Rule ID/Parent ID не то же самое - последовательное зависимое применение правил?

Instructor · Post by **Instructor** » Wed Jun 08, 2016 9:10 am

Drugmix wrote:
Code: Select all
0	`(")((?:[^"]|"")*+)(")` `\1=(0,#ffff00,0) \2=(0,#00ffff,0) \3=(0,#ffff00,0)`	-3	0
работает. Хочу к нему приделать дочернее правило и потому присваиваю Rule ID = 1:
Code: Select all
0	`(")((?:[^"]|"")*+)(")` `\1=(0,#ff0,0) \2=(0,#0ff,0) \3=(0,#ff0,0)`	-3	1
И оно крэшится...

Падение не воспроизводится, но проблема ясна - правило становится родителем для самого себя. См. тестовую и Coder 19.7.

вот свежий пример

Подсветка по указанным правилам не соответствует тому, что на картинках.

Можно ... чтобы при этом отдельно ото всего работали и нынешние правила сворачивания блоков (т.е. между /* и */, и между { и })?

Нет.

Instructor · Post by **Instructor** » Wed Jun 08, 2016 9:21 am

Изменено: правило с "Parent ID" -2 или -3 не обрабатывается, если не нулевой идентификатор правила и родителя совпадает ("Quotes:", "QuotesRE:", "Folds:").

Changed: rule with "Parent ID" -2 or -3 ignored if non-zero identifiers of rule and parent matches ("Quotes:", "QuotesRE:", "Folds:").

Coder plugin v19.7

Drugmix · Post by **Drugmix** » Wed Jun 08, 2016 4:07 pm

Instructor wrote:Подсветка по указанным правилам не соответствует тому, что на картинках.

Как это? У меня соответствует.
У меня по-прежнему так же раскрашивает и на свежей версии coder плагина. AkelPad 4.9.7 x64, если что. Могу и папку выслать.
Проверил этот же coder и на вашей тестовой версии с последним релизным coder - окрашивается так же.

Instructor wrote:Падение не воспроизводится, но проблема ясна - правило становится родителем для самого себя. См. тестовую и Coder 19.7.

Проверил, да, на тестовой не падает.

Instructor wrote:
Можно ... чтобы при этом отдельно ото всего работали и нынешние правила сворачивания блоков (т.е. между /* и */, и между { и })?
Нет.

Жалко, что нет.
И даже чёрт с ней со свёрткой /* */ блоков - мне бы достаточно было если бы просто они красились бы в (3,${COMM},0), но я так понимаю, что и это невозможно, т.к. ни Quotes, ни QuotesRE правила не многострочны, в отличие от этих блоков

Skif_off wrote:Имеет, в любом правиле и секции.

Спасибо, ещё одна мудрость присутствующая только в виде форумных сказаний

Skif_off wrote:И вы так и не прояснили, что подразумевается под "каскадным применением правил"? Разве Rule ID/Parent ID не то же самое - последовательное зависимое применение правил?

Сейчас когда я побольше потыкался с Rule ID/Parent ID - я начинаю понимать, что это довольно близкие вещи, получается разница лишь в некоторых моментах:
1. в иерархии, а конкретно в вопросе: если в каскадном применении правил у одного условно дочернего (т.е. более поздно идущего) правила могут быть несколько условных родителей (т.е. все сработавшие правила из тех, что идут перед ним) и между ними не нужно явно задавать взаимосвязь, то в системе RuleID/ParentID - у дочернего правила надо явно указывать родителей, а т.к. нельзя сослаться на родителей указав несколько ParentID - приходится изменять структуру правил так, чтобы все желаемые родители имели одинаковый ParentID, а это уже ломает структуру, ведь получается, что эти правила становятся одного уровня, а в каскадной системе они могли иметь и условную взаимосвязь родительское<>дочернее правило.
Т.е. если у нас есть 4 правила, в каскадной системе они применяются поочерёдно (при этом срабатывая или нет, в зависимости от match (вхождения)):
A > B > C > D.
А в системе RuleID/ParentID
Они для дочернего правила D будут доходить
или как [A или B или C] > D и уже теряется информация, что правило B должно быть дочерним к A.
или как A > B > C > D, но тогда D всегда не будет срабатывать, если не сработает или А или B или C или группы из них, в отличие от случая каскадного применения правил.

2. из-за отсутствия 'fallback'ов (про которые я выше упоминал) может так случиться, что часть строки окажется неокрашенной, т.к. её окрасило первое правило, а потом сработало второе правило (дочернее к первому) и т.к. во втором правиле подкрашивается только часть вхождения - другая часть сейчас теряет подсветку совсем, как я это продемонстрировал на скриншотах выше.

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

Skif_off · Post by **Skif_off** » Thu Jun 09, 2016 9:36 am

Drugmix
Если правильно понял, с A > B > C > D всё-таки можно что-то сделать:

Code: Select all

> A - не оформленное правило           ParentID = 0    RuleID = 1
  > A1 - оформленное правило           1    0
  > A2 - оформленное правило           1    0
  > An - оформленное правило           1    0
  > B  - не оформленное правило        1    2
    > B1 - оформленное правило         2    0
    > B2 - оформленное правило         2    0
    > Bn - оформленное правило         2    0
    > C  - не оформленное правило      2    3
      > C1 - оформленное правило       3    0
      > C2 - оформленное правило       3    0
      > Cn - оформленное правило       3    0
      > D  - не оформленное правило    3    4
        > D1 - оформленное правило     4    0
        > D2 - оформленное правило     4    0
        > Dn - оформленное правило     4    0

Но это будет та ещё задачка

На всякий случай:
- не оформленное правило - Font style = 0, Color text = 0, Color bkgrnd = 0
- оформленное правило - Font style <> 0 или Color text <> 0 или Color bkgrnd <> 0

Drugmix · Post by **Drugmix** » Thu Jun 09, 2016 11:32 am

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

А какой смысл в неоформленных правилах? Правила же создаются только для подсветки.

Skif_off · Post by **Skif_off** » Thu Jun 09, 2016 4:14 pm

Drugmix
Родительское правило нужно, чтобы локализовать часть текста, которое будет подсвечено уже дочерними, зачем им подкрашивать? Так без сюрпризов.
Возможно, ошибаюсь, сужу по примерам - xml, css, html.

DV · Post by DV » Fri Jun 10, 2016 7:39 am

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