Well, the parsing of the formatting symbols is only from left to right, i.e. the missing closing symbol can't cancel the open symbol action. The rules are following:
The formatting starts with not escaped formatting symbol (\/ \* \_ \` \-) preceded by a white-space character.
The formatting ends by either the same symbol, followed by a white-space, or by the end of the paragraph.
The new lines symbols are white-space characters in this context.
The only formatting that behaves different is bold (*) which does not end at the end of the paragraph and expect explicit closing symbol. In your example, the open asterisk is in the first paragraph, and the closing in the next (not counting the escaped one).
This behavior is wrong and should be fixed of course.
But there is another problem. Recently I am working on a second markup parser for the posts, compatible with BBCode. But because I want to make both parsers available simultaneously, I have to rework the current parser in order to make it faster and interface compatible with the BBCode parser. Because of this work, the fixes will be delayed a little.
I would be really, really pushing it to ask for a third one: markdown parser
BBCode precedes markdown historically but it looks a lot like HTML with square bracket tags. Markdown reduces the tags to single characters, just like the asmbb character tags. Makes for more readable raw text during composition and when viewed elsewhere. The resulting text can be stored elsewhere too, such as in a Fossil repository, which happens to have a markdown
parser.
Choosing an original source document format is a vexing problem because none is convertible to every other format.
I would be really, really pushing it to ask for a third one: markdown parser
The current AsmBB format is inspired by markdown and is partially compatible. I though about implementation of fully compatible with commonmark parser and maybe some day will implement it as well.
But I needed BBCode first in order to allow easy porting from other forum engines, because most of them use BBCode.
Would you please improve the markdown support? It should full support markdown definition for new user that get used to with "normal markdown".
Some render problems exist when - * begin and no end but still interpreted as markdown code:
test for a normal list line begin with "" and end with new line
test for a normal list line begin with "" and end with new line
and we have to double new line to made render as new line (str1+\r\n+\r\n+str2 => str1 in line 1 and str2 in line 2 after render )
Thank you!
Well, I have some plans to fix these issues, but unfortunately it is not so easy task. At first because of backward compatibility. Making MiniMag markup compatible with MarkDown will break a lot of the previous formatting.
And also, the parsing strategies are different which will need a serious code changes.