[foo [bar a;b blah blah]]
i was worried this might turn up an edge case in
valid_ending_pos -- and it did, but not in the manner I had anticipated. I thought the immediate nesting, with no intervening attributes or content, might break something. That part worked just fine, but the cuddled terminators weren't behaving properly at all.What should happen is
- The Text handler sees ']]', quits processing, and returns
- The Tag handler is called, sees ']]', which begins with its markup terminator, and claims responsibility
- Tag consumes its terminating markup (']'), and pushes the remainder (also ']') back on to the Lexer's next-token stack
- Tag is called again and the final ] is consumed
- Text sees ']]', pushes it onto the Lexer's next-token stack, quits processing, and returns
- Lexer, knowing that it is at physical EOF, sets its status to 1 (EOF, but I have synthetic tokens in stack)
- Tag is called, consuming a token from the stack, which happens to be the only token in the stack.
- Lexer gives Tag the token and sets its status to 99 (EOF, no synthetic tokens)
- Tag calls
valid_ending_poswhich has the statement'return 1 if $l->status == 99'right up top. This is meant to let Triggers and Verbatim contexts always have a valid ending at EOF. - Lexer's status is 99
- Tag does not execute the code at the bottom of
valid_ending_pos, which performs the separation of terminating markup from the current token and the subsequent injection of the remainder onto Lexer's next-token stack (which would have reset its status to 1), allowing for cuddled terminators (and sloppiness like'foo]bar'). - The current token, containing the terminators for both open tags, is thrown away
- The test suite calls Tag again to process the second terminator.
- Lexer returns undef; tests fail
No comments:
Post a Comment