Skip to content

Region strings' syntax highlighting is broken when they're defined as part of another region themselves #4148

Description

@chaosDesigner99

Description

I was attempting to do something like the following to add syntax highlighting for PHP's attributes:

# ~/.config/micro/syntax/php.yaml

# Other rules above
- special:
    start: "#\\["
    end: "\\]"
    rules:
        - constant.string:
            start: "'"
            end: "'"
            skip: "\\\\."
# Other rules below

When defined as a above, attributes themselves will be highlighted properly in a PHP file (when placed above the one-line comment definition), but if the attribute contains a string, the string will only be highlighted properly until it matches any other rule in the file, even if it's not defined within the string region itself, as well as the closing quotation mark. For example, in the following code:

#[SomeAttribute('A very !long string *here with /some +symbols')]

Since the exclamation mark character is defined in another, unrelated rule as an operator in the same file, Micro will only highlight the initial 'A very ! and the final ' as a string. The text in between will be highlighted as regular text, following rules defined outside of the attribute region, even before it in the file (when the colors help file states that rules further down in the file should have more priority than rules above them). So string will be highlighted as a type, and *, / and + will be highlighted as operators.

I have tried the same with other region rule definitions, and it seems to be a generalized problem for strings defined as regions within regions. Perhaps other rule definitions besides strings would suffer from this problem. It's worth testing further.

It is worth noting that changing the above YAML configuration to the following does not have this effect:

# ~/.config/micro/syntax/php.yaml

# Other rules above
- special:
    start: "#\\["
    end: "\\]"
    rules:
        - constant.string: "'.*?'"
# Other rules below

The code above doesn't present the same problem, and in this case, strings will only be overwritten based on rules defined below them as part of the same attribute region.

Environment

  • Version: 2.0.13
  • OS: Linux Mint 22.3
  • Terminal: GNOME Terminal

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions