https://bugs.kde.org/show_bug.cgi?id=399388
Bug ID: 399388
Summary: IncludeRules breaks dynamic RegExpr matching
Product: frameworks-syntax-highlighting
Version: 5.50.0
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: syntax
Assignee: kwrite-bugs-n...@kde.org
Reporter: mrchristopherjac...@gmail.com
Target Milestone: ---
Created attachment 115415
--> https://bugs.kde.org/attachment.cgi?id=115415&action=edit
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
--
You are receiving this mail because:
You are watching all bug changes.
