This is complex.
First your markup above is problematic and probably illegal (though I don't advocate it should be allowed to cause php errors!). The second list doesn't have a list terminating pattern prior to the footnote closure. Since the list isn't closed, the parser isn't in the footnote syntax mode, ergo, it isn't matching for the footnote exit pattern. Therefore "))" goes through as CDATA. When the wiki document is finished only the second list is closed, leaving the first list unclosed and unprocessed (as well as the footnote unclosed).
So I modified the markup to try to make it legal.
* (( B
This still causes the parser problems.
< many head scratches, much time passes ;-) >
Its the CallWriters - they could probably do with being rewritten into an inheritable class structure, in fact it seems strange that they aren't. All except the Doku_Handler_CallWriter have a writeCalls method used to merge their calls with the next outermost call writer. Only after merging they call the next outermost CallWriter and tell it to do the same - only it won't have processed its instructions yet. Hence in this case the unrecognised (unprocessed) list_open instruction.
I'll forward a patch. It does two things.
- remove the chaining of CallWriter writeCalls methods
- adds a finalise method to each call writer. The handler will call its current call writers finalise method when it commences its own finalisation (ie. _finalise()). In a properly contructed wiki page, only the main call writer will be involved and it doesn't need to do anything. If unclosed syntax modes are in effect, the finalise method should:
- issue any instructions for closing its syntax mode
- process its instructions
- merge its instructions with the next outermost call writer
- call that call writer's finalise method
The ensuing chain of call writer finalisation will stop at Doku_Handler_CallWriter which knows its the first/highest in the chain.
Back to your original wiki-markup. This prevents the php error. It does not correct the html. Because the footnote closure is missed and because footnote doesn't use a call writer, the end page is missing a </div> which will mess up the rest of the page. A solution would be to give footnote its own call writer. That's for another day - and should probably include a proper inheritable class structure for call writers.