Closed charliehoward4dp closed 11 months ago
I'll also consider whether it's feasible to make "Unmatched Block Markup Check" do a better search (requiring the blank line in the appropriate place). However, the way it's written, that might not be easy, and wouldn't be necessary if your request above was done.
Enhancing "Unmatched Block Markup Check" would be difficult, in my opinion, because it would have to account for the presence or absence of page separators on the line just above the opening block quote, and whether or not the previous page ended with a closing block quote, whether or not page separators have been removed, and whether there is one bq spanning two pages or two separate bq’s or a malformed bq. This condition happens rarely (I’ve never seen this error message before), and it’s both easier and safer to let a person figure it out. So, I still prefer a hint added to the error message or a mark placed on the closing bq.
Fair enough - I won't waste time on looking at enhancing the check then. Thanks
This is on the fence between being a bug and being a feature request. The attached file contains a block quote error at line 6586: the opening /# should follow, not precede, the blank line. "Rewrap All" displays the following message:
11:32:19: Close blockquote (#/) found with no matching open markup
It would be more helpful if it included information making it easier to identify WHICH closing blockquote was found (there are 106 BQ's in this file). Possibilities include putting some unique string into the main file, right after the offending #/, or including some of the actual text that preceded the #/ in the message.
"Unmatched Block Markup Check" doesn't detect this (they are balanced, after all).
To find the problem, it was necessary to do a series of ever-smaller "Rewrap Selection"s.
wrapbug.zip