Подсветка в Kate

Признавайся, ЛОР, ты занимался раскраской кода в Kate?

Когда-то в дремучие времена KDE4 колупал. Судя по твоему посту, принцип остался тот же.

А что тебе конкретно требуется в таком синтаксисе? В смысле после foo=bar не должно быть такого же синтаксиса в той же строчке? Или между ними должна быть запяятая?

Там может быть всё что угодно в предложении, главное, что само правило foo=bar об этом знать не должно, оно должно распарсить свой кусок и выйти в контекст, из которого его вызывали. Предположим вот такой вариант:

myrule(myrule), myrule;

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

myrule(myrule), myrule;

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

Хм, наверное, ты это уже сделал, но для (контекста) myrule надо задать условия (правила) выхода (как например <RegExpr ... lookAhead="true" context="#pop"/>)

А в контексте описующем <myrule>(<myrule>), <myrule>; тоже дописать правил:

• <RegExpr String="^ context="myrule" ...
• <DetectChar char="(" context="myrule" ...
• <Detect2Char char=",(" context="myrule" ...
• <DetectChar char=";" context="#pop" ...

Получится, если зайти в myrule через это правило:

<DetectChar char="(" context="myrule" ...

и myrule выйдет через #pop, то мы вернёмся в предыдущий контекст. В котором будет парситься что-то вроде:

(myrule)(myrule)(myrule)

И не совсем понятно зачем нужен lookAhead=«true», разве это не значит, что при возврате в родительский контекст он продолжит парситься со слов «myrule»? Нужно ведь вернуться после этих слов, чтобы далее была закрывающая скобка.

И не совсем понятно зачем нужен lookAhead=«true»

Это для возврата из myrule, если задетектит ненужный символ

Сейчас, ради спортивного интереса накидаю. Только разберусь почему Kate падает от моего файла...

Ну, вроди вот https://pastebin.com/60MfUWxZ

Правда, как оказалось <RegExpr String="^" ... не срабатывает надо что-то другое

Спасибо за попытку. Как и ожидалось, срабатывает на текст вида:

foo=bar),a=b), c=d

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

Ага, теперь кажется я понял проблему (и сам даже на нее натолкнулся).

А для скобочек можно использовать dynamic rule. Только я его еще тогда не осилил

Смысл dynamic rule вроде понятен — вложенный контекст получит переменные из родительского. Звучит многообещающе, но и только. На практике эти переменные приходят исключительно из регулярных выражений и использовать их можно только при поиске вложенного правила. То-есть можно автоматически закрывать скоупы вроде function/endfunction, if/endif, но при этом неясно как быть, скажем, со скобками {}.

Подошло бы даже что-то вроде <SomeRule ... context="myrule" nextContext="foo"/>, а внутри самого myrule можно было бы подставить значение «foo» в возвращаемый контекст: <StringDetect ... context="#pop#pop#next"/>.

Может и можно сделать что-то подобное.

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

Послесловие.

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

Синтаксис должен проверяться отдельным линтером и это уже другая задача.

Единственное, что допускается в Kate для обработки корректности это <context ... fallbackContext="..."/> чтобы избежать случаев мелькающей подсветки в процессе набора текста, пока код ещё не завершён. К примеру:

struct Foo {}

За фигурной скобкой должна всегда следовать точка с запятой, но даже если её нет, код после такого объявления должен подвечиваться нормально без мелькания в процессе набора.

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

https://docs.kde.org/stable5/en/applications/katepart/highlight.html Ну там так и написано:

Syntax highlighting is there to enhance the readability of correct text, but you cannot trust it to validate your text. Marking text for syntax is difficult depending on the format you are using, and in some cases the authors of the syntax rules will be proud if 98% of text gets correctly rendered, though most often you need a rare style to see the incorrect 2%.