Unmatched Block Markup Check misses a certain kind of error

[charliehoward4dp]

The Block Markup Check doesn't catch this (line 4):

If he invites Phyllis to love him and live with him
in the country, he reduces the hills for her to
the size of bric-à-brac:
n/P
Thy feasting-tables shall be hills
With daisies spread, and daffodils.
P/

(This must have been caused by a badly-typed regex, whose replacement string should have been \n/P).

Possible remedy: require block markups to begin at the very beginning of a line.

[windymilla]

Notes for whoever fixes this ;)

Problem is in unmatcheditemsrun. It gets passed this regex: "^(/[$::allblocktypes]|[$::allblocktypes]/)\$" This correctly skips the n/P but finds P/. However, having found the index of the matching text, it then gets the text (P/) calculates what the matching text should be (/P) and searches backwards for it, and finds it.

So the problem is that the start/end of line anchors ^ and $ are passed in correctly originally, but become lost in the process of actually locating the match and determining its mirror tag.

Best solution might be to have an (optional?) argument to unmatcheditemsrun, to say whether the item being matched should be anchored at the start of a line.

Question: does it currently work if extra margin arguments are given, e.g. /#[10.4]? It looks like it might skip the opening markup, because the # is not at end of line, but then it finds the closing markup, and (due to the above bug) finds the opening markup, even though it is not at end of line. Solution for that may be to make the regex tolerate the margin args, and also for hilitematchblock to cope with mirroring that too.

[charliehoward4dp]

Answer to question: No, it still says there are no errors.

[windymilla]

Thanks - I suspected as much, as it doesn't look like the code even tries to cope with it. I blame the programmer!