Created attachment 115415 [details]
highlight definition file

SUMMARY

If a highlighting context uses `<IncludeRules context="..."/>` to include the rules from another context that contains a dynamic regular expression match (e.g. `<RegExpr String="%1" dynamic="true".../>` the *second* context becomes broken if it matches anywhere on the same line as the *first* context. Specifically, only the RegExpr rule stops matching correctly.

I've attached a very simple syntax highlighting definition file to illustrate. It only recognizes a single construct: a literal capital letter 'X', followed by a delimited string. The delimiter can either be a pair of matching parentheses, a pair of matching braces, or any other non-space character (where the end of the string occurs whenever the initial delimiter is matched again). If you're familiar with Perl's matching operator, it's basically a very stripped down version of this. Other than this simple setup, there are some bogus "keywords" that get matched _only_ inside the string, just to prove that these rules appear to working correctly.

The only difference between the two bracket-like contexts (other than the delimiter) is the way in which they "inherit" the keyword matching rules from the "generic" context. The brace-context uses the `<IncludeRules context="...">`, while the paren-context simply contains the copy-pasted content.

Generally, all of these contexts work well when the constructs they match are alone on a line. That is, all of the following highlight correctly:

    normal X(string with This and That and other) normal
    normal X{string with This and That and other} normal
    normal X:string with This and That and other: normal

The paren-delimited and generic-delimited contexts will similarly highlight everything correctly when paired in the same line:

    normal X(string with This and That and other) normal X(string with This and That and other) normal
    normal X(string with This and That and other) normal X:string with This and That and other: normal
    normal X:string with This and That and other: normal X(string with This and That and other) normal
    normal X:string with This and That and other: normal X:string with This and That and other: normal

But things stop working when the brace-delimited construct _precedes_ a generically-delimited construct:

    normal X{string with This and That and other} normal X:string with This and That and other: this is _not_ normal

The generic-delimited context doesn't recognize the ':' delimiter and the text after it will continue matching against the rules in that context. The other-way around works just fine:

    normal X:string with This and That and other: normal X{string with This and That and other} normal again

The contexts pop at end-of-line, so things are restored to normal whenever a newline occurs. Things get a little more interesting when `lineEndContext="#stay"` is applied. The patterns above still hold, except that in the broken scenario, if a ':' is found on any subsequent line, it is recognized:

    normal X{string with This and That and other} normal X:string with This and That and other: this is _not_ normal
    string continues to new line: <- delimiter recognized, normal again

SOFTWARE VERSIONS
(available in About System)
KDE Plasma Version: 5.50.0
KDE Frameworks Version: 5.50.0
Qt Version: 5.11.2