LINUX.ORG.RU

Подсветка в Kate

 , ,


0

1

Пытаюсь наваять подсветку в своём языке следуя документации: https://docs.kde.org/stable5/en/applications/katepart/highlight.html

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

К примеру, есть синтаксис, для которого написаны контекст и правила:

foo=bar

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

foo=bar foo=bar

Хотя по правилам языка между ними должна быть запятая. Можно создать контекст, который будет сначала требовать запятую. Но никак не могу понять, как существующее правило foo=bar должно в него вернуться, ведь единственный предусмотренный способ это #pop.

Есть вариант сделать #pop!my_context_with_leading_coma. Но возвращаемся к нашим баранам — правило foo=bar повторяется в совершенно разных местах, каждый из которых имеет свой синтаксис, то-есть !my_context_with_leading_coma это частный случай и захардкодить его нельзя.

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

★★★★★

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

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

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

KennyMinigun ★★★★★
()
Ответ на: комментарий от KennyMinigun

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

myrule(myrule), myrule;

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

Dendy ★★★★★
() автор топика
Ответ на: комментарий от Dendy
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" ...
KennyMinigun ★★★★★
()
Последнее исправление: KennyMinigun (всего исправлений: 3)
Ответ на: комментарий от KennyMinigun

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

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

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

(myrule)(myrule)(myrule)

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

Dendy ★★★★★
() автор топика
Ответ на: комментарий от Dendy

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

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

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

KennyMinigun ★★★★★
()
Ответ на: комментарий от KennyMinigun

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

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

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

Dendy ★★★★★
() автор топика
Ответ на: комментарий от Dendy

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

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

KennyMinigun ★★★★★
()
Ответ на: комментарий от KennyMinigun

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

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

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

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

Dendy ★★★★★
() автор топика
Последнее исправление: Dendy (всего исправлений: 1)
Ответ на: комментарий от KennyMinigun

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

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

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

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

struct Foo {}

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

Dendy ★★★★★
() автор топика
Ответ на: комментарий от Dendy

Насколько я понял, идея подсветки синтаксиса в 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%.

KennyMinigun ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.