-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix block handling in template processor #2448
base: master
Are you sure you want to change the base?
Conversation
86bf46e
to
19ca448
Compare
2d9f999
to
e458249
Compare
- more relaxed but reliable regexp to detect blocks - support multiple blocks with same name
19ca448
to
50e23b2
Compare
@coveralls don't be that pedantic. |
Why don't you use the In some way it has the same logic as your regexp, but your regexp seems complex for big files. Whereas findContainingXmlBlockForMacro use first findMacro to find it straight, then from the position found, search for the first opening w:p. I had reflexion about this problem, and my conclusion is not everything should be done by regexp to manage well complexity (else the regexp would use Lookahead or Lookbehind feature that are having complexity far more than O(n)). I also customized a little bit this function, like /** And then customized findMacro to be able to compare different algorithm; Off course, all of this is dependant of the fixBrokenMacros that is also modified to be able to fix merge all the w:t including tha macro without breaking style and other data. So, sorry for my long post, but the summary is that breaking the problem in function seems to be a good way to organise the TemplateProcessor processing. What do you think ? |
Any update on this PR? |
BUMP |
This doesn't always work. Didn't work for me when used wrapping over a table. |
Any update of this fix please? |
maybe fixes #2444, #2410
related: #1836, #1354
Checklist:
composer run-script check --timeout=0
and no errors were reported