Relevant excerpts from IRC: <Silver> If you made mungePriority work all the way through a string, you'd not need to check the same priority in recursion. * Gijs actually proposes getting rid of the talkback munger, if we're on the subject <Gijs> nobody uses that anymore. <Silver> It's a little more complex than just sorting, but not much. <Silver> As I understand it, any munger match that starts before the end of the current match is invalidated. <Silver> Then you just need to re-scan any mungers that got invalidated and start again. <Silver> (Obviously shifting the non-invalidated ones along.) <Gijs> Silver: by the latter statement, you mean shifting the stored position of the matches based on the shorter string that you work with? <Silver> Gijs: Yes, or some equivalent. <Silver> Since you've replaced a chunk in the middle, you're now working on the right-hand-side of that match. <Silver> That'd work you left-to-right through the string doing all the $priority mungers. The bits between each match - and at both ends - would need to recurse, but don't need to consider >=$priority mungers. <Glenjamin> so you reckon we can retain the matches for any munger with start > first.end, discard any mungers which didnt match the first time, and re-run the ones with stat < first.end, and first itself <Glenjamin> recursing the bits which match nothing into the lower priorities <Silver> The munger that was selected, and any with start < first.end, need to be redone. That's all AFAICT. <Gijs> what about the leftcontext though... you would only need to match lower priority there, right? <Silver> Yes, all the non-matching parts go to lower priority mungers only. <Silver> (Left of each match and then remaining chunk.) <Silver> If you recurse all the blocks, you don't need the priority loop as such - it just picks the highest priority its allowed to and uses that.
You need to log in before you can comment on or make changes to this bug.