This revision was automatically updated to reflect the committed changes.
Closed by commit R216:02a3fb1d7c39: Small improvements in some XML files
(authored by nibags, committed by cullmann).
REPOSITORY
R216 Syntax Highlighting
CHANGES SINCE LAST UPDATE
cullmann accepted this revision.
cullmann added a comment.
This revision is now accepted and ready to land.
I think we can go with this as is.
Given we have tests for a lot of stuff, regressions shouldn't be that likely.
I will merge this, before we let that rot even more.
Thanks for the
nibags updated this revision to Diff 70781.
nibags added a comment.
- Resolve conflicts
REPOSITORY
R216 Syntax Highlighting
CHANGES SINCE LAST UPDATE
https://phabricator.kde.org/D24982?vs=70779=70781
REVISION DETAIL
https://phabricator.kde.org/D24982
AFFECTED FILES
nibags updated this revision to Diff 70779.
nibags added a comment.
- Resolve merge conflicts.
REPOSITORY
R216 Syntax Highlighting
CHANGES SINCE LAST UPDATE
https://phabricator.kde.org/D24982?vs=68824=70779
REVISION DETAIL
https://phabricator.kde.org/D24982
AFFECTED FILES
nibags added a comment.
Captures can also be used without dynamic rules, for example in the regular
expression: `(+)[^]*\1`
In these cases, a `capture="true"` attribute can be used to enable captures,
but in dynamic rules the detection will be automatic.
I could do a benchmark the
dhaumann added a comment.
I think we should decide what to do with this patch, as over time it will get
merge conflicts.
In general, I hoped we can have some sort of auto detection to disable
captures in a smart way.
If this is not possible, maybe we should accept this patch?
cullmann added a comment.
Could we perhaps just do some minimal checking like "no dynamic stuff at all"
=> turn off all captures?
REPOSITORY
R216 Syntax Highlighting
REVISION DETAIL
https://phabricator.kde.org/D24982
To: nibags, #framework_syntax_highlighting, dhaumann, cullmann
Cc:
dhaumann added a comment.
Hm right... too bad. I was hoping to find an automated way to detect this.
Since relying on the user to optimize the RegExps will always be suboptimal.
@cullmann Do you have any ideas?
REPOSITORY
R216 Syntax Highlighting
REVISION DETAIL
nibags added a comment.
No, the dynamic flag is used to insert the captures already stored in `%N`
(the captures are stored in the RegExpr rules and then "inserted" in the rules
with the dynamic flag)
REPOSITORY
R216 Syntax Highlighting
REVISION DETAIL
dhaumann added a comment.
> [...]
> One option would be to add a **capture** or **dontCapture** attribute to
enable or disable captures for RegExpr rules. Also, captures could be enabled
or disabled in all RegExpr rules using the group, adding an
element for that.
But don't we
nibags added a comment.
I had also thought about using `QRegularExpression::DontCaptureOption`, which
is equivalent to using `(?:...)`, but I wasn't sure how much the real
improvement in performance is. However, disabling captures avoids allocating
unnecessary QString for each capture.
dhaumann added a comment.
I wonder if the `?:` optimizations make sense. QRegularExpression has the
option `QRegularExpression::DontCaptureOption` to not capture anything. Looking
into our code we have:
561 bool RegExpr::doLoad(QXmlStreamReader& reader)
562 {
563
nibags updated this revision to Diff 68824.
nibags added a comment.
- Increase version of javascript.xml
REPOSITORY
R216 Syntax Highlighting
CHANGES SINCE LAST UPDATE
https://phabricator.kde.org/D24982?vs=68823=68824
BRANCH
improve-some-xml
REVISION DETAIL
nibags created this revision.
nibags added reviewers: Framework: Syntax Highlighting, dhaumann, cullmann.
Herald added projects: Kate, Frameworks.
Herald added subscribers: kde-frameworks-devel, kwrite-devel.
nibags requested review of this revision.
REVISION SUMMARY
**Changes:**
- Replace
14 matches
Mail list logo
