Правильно ли область действия цитируемых (строковых) констант в tmLanguage?

Я являюсь автором и сопровождающим Набора WoW для кода Visual Studio.

В API Blizzard World of Warcraft многие константы, такие как имена событий, обработчики скриптов виджетов или определенные параметры функций, являются строками. Эти строки могут быть заключены в одинарные или двойные кавычки, а некоторые (не все) из них нечувствительны к регистру. Например:

local myFrame = CreateFrame('Button', nil, UIParent)
myFrame:SetPoint('CENTER', 0, 0)
MyFrame:RegisterEvent('PLAYER_ENTERING_WORLD')
myFrame:SetScript('OnEvent', myEventHandler)

Чтобы охватить эти специальные строки в моем файле tmLanguage, я объявляю их в репозитории:

<!-- This is only an excerpt, there are many more of these :) -->
<key>repository</key>
<dict>
    <key>string-parameters</key>
    <dict>
        <key>match</key>
        <string>(?i)(Button|Frame|Slider|StatusBar|TOP|LEFT|BOTTOM|RIGHT|BACKGROUND|ARTWORK|LOW|MEDIUM|HIGH)</string>
        <key>name</key>
        <string>support.constant.wow.parameter.lua</string>
    </dict>
    <key>event-names</key>
    <dict>
        <key>match</key>
        <string>(PLAYER_ENTERING_WORLD|ADDON_LOADED)</string>
        <key>name</key>
        <string>support.constant.wow.event.lua</string>
    </dict>
    <key>script-handlers</key>
    <dict>
        <key>match</key>
        <string>(OnLoad|OnShow|OnEvent)</string>
        <key>name</key>
        <string>support.constant.wow.hander.lua</string>
    </dict>
</dict>

и я включаю их в окружающую область:

<dict>
    <key>name</key>
    <string>support.constant.wow.quoted.single.lua</string>
    <key>begin</key>
    <string>'</string>
    <key>beginCaptures</key>
    <dict>
        <key>0</key>
        <dict>
            <key>name</key>
            <string>punctuation.definition.constant.begin.lua</string>
        </dict>
    </dict>
    <key>end</key>
    <string>'</string>
    <key>endCaptures</key>
    <dict>
        <key>0</key>
        <dict>
            <key>name</key>
            <string>punctuation.definition.constant.end.lua</string>
        </dict>
    </dict>
    <key>patterns</key>
    <array>
        <dict>
            <key>include</key>
            <string>#string-parameters</string>
        </dict>
        <dict>
            <key>include</key>
            <string>#event-names</string>
        </dict>
        <dict>
            <key>include</key>
            <string>#script-handlers</string>
        </dict>
    </array>
</dict>

Конечно, у меня есть два таких блока (один для одинарных кавычек, один для двойных кавычек), и они объявлены перед блоками обычных строк, чтобы убедиться, что они имеют приоритет.

Итак, это работает... почти.

В объявлениях типа:

local myFrame = CreateFrame(' Frame ', nil, UIParent)  -- Notice the spaces around Frame

или хуже:

local myFrame = CreateFrame('Frame Type That Does Not Exist', nil, UIParent)

вся строка по-прежнему анализируется как действительная (поскольку она содержит слово Frame из репозитория #string-parameters), хотя очевидно, что этого не должно быть.

Как сделать так, чтобы из репозиториев совпало только одно слово без пробелов? Я пытался изменить регулярные выражения разными способами, но безрезультатно.


person Stephan Schreiber    schedule 14.10.2016    source источник
comment
Из-за отсутствия ответов :) Я, наконец, пошел другим путем и сумел правильно раскрасить свою строку. Я оставлю вопрос открытым для любого, кто в конечном итоге даст ответ.   -  person Stephan Schreiber    schedule 15.10.2016


Ответы (1)


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

Кстати, знаете ли вы, что вы также можете использовать JSON для определения своих правил, который намного легче читать, чем XML? Например, см. мой файл синтаксиса здесь.

person Mike Lischke    schedule 16.10.2016