Поскольку я не могу найти какие-либо рекомендации по подсветке синтаксиса, я решил подготовить простой предварительный просмотр записи в виде обычного текста и затем выделение всего в html, что достаточно для моей области на данный момент.
Переопределяя многие пользовательские классы метамодели, у меня есть метод to_source
, который фактически переопределяет весь синтаксис в обратном порядке, так как обратный анализ пока недоступен. Это нормально, но игнорирует пользовательское форматирование.
Для сохранения пользовательского форматирования мы можем использовать только доступную вещь: _tx_position
и _tx_position_end
. Переход от основного правила textX к его дочерним элементам с помощью сохраненных пользовательских атрибутов классов метамодели работает в большинстве случаев, но он завершается неудачно с примитивами.
# textX meta-model file
NonsenseProgram:
"begin" foo=Foo "," count=INT "end";
;
Foo:
"fancy" a=ID "separator" b=ID "finished"
;
# textX custom meta-model classes
class NonsenseProgram():
def __init__(foo, count):
self.foo = foo
self.count = count
def to_source(self):
pass # some recursive magic that use _tx_position and _tx_position_end
class Foo():
def __init__(parent, a, b):
self.parent = parent
self.a = a
self.b = b
def to_source(self):
pass # some recursive magic that use _tx_position and _tx_position_end
Рассмотрим приведенный пример. Поскольку у нас есть классы NonsenseProgram
и Foo
, которые мы можем переопределить, мы контролируем возвращаемый источник в целом. Мы можем изменить сгенерированный код NonsenseProgram
, фрагмент NonsenseProgram.foo
(переопределив Foo
), используя его атрибуты _tx_*
. Мы не можем сделать то же самое с NonsenseProgram.count
, Foo.a
и Foo.b
, поскольку у нас есть примитивное значение string
или int
.
В зависимости от использования примитивов вне грамматики у нас есть следующие опции:
- Оберните каждый примитив правилом, которое содержит только этот примитив и ничего больше.
Плюсы: это просто работает прямо сейчас!
Минусы: создает огромные накладные расходы на вложенные значения, которые должен обрабатывать наш набор грамматических инструментов. Это на самом деле портит грамматику только за то, что она красивая ...
- Игнорировать синтаксис от пользователя и использовать только наши правила обратного анализа.
Плюсы: это тоже работает!
Минусы: вам нужно переопределить ваш синтаксис почти с каждым элементом грамматики. Это заставляет переформатировать код при каждой попытке выделения.
- Используйте некоторые внешние правила подсветки.
Плюсы: это будет работать ...
Минусы: Снова повторная реализация грамматики.
- Использовать языковой сервер.
Плюсы: будет лучшим вариантом в долгосрочной перспективе.
Минусы: Упоминается только один раз без каких-либо подробных документов.
Есть предложения по поводу других вариантов?