I assume the definition of a strikethrough fragment is that it starts and ends with a dash.

e.g. this is struck through

But this is also handled the same way by the parser and does not have the terminating dash.

I think this is a parser bug.

How does one use a dash in the text as just a dash? Let's see if backslash dash works:

\-This should not be struck through.- Notice that the trailing dash is NOT displayed. I think this is a parser bug.

Can the others be escaped?

Should not be bold. (leading asterisk but no trailing)

\*Should not be bold.* (escaped leading asterisk plus a trailing one)

Should not be underlined. (leading underscore but no trailing)

\_Should not be underlined._ (escaped leading underscore plus a trailing one)

Definitely some inconsistency here.

I'm writing some documentation for my own purposes and will give it to you when I'm done.

crustyoz

I assume the definition of a strikethrough fragment is that it starts and ends with a dash.

e.g. this is struck through

But this is also handled the same way by the parser and does not have the terminating dash.

I think this is a parser bug.

How does one use a dash in the text as just a dash? Let's see if backslash dash works:

\-This should not be struck through.- Notice that the trailing dash is NOT displayed. I think this is a parser bug.

Can the others be escaped?

Should not be bold. (leading asterisk but no trailing)

\*Should not be bold.* (escaped leading asterisk plus a trailing one)

Should not be underlined. (leading underscore but no trailing)

\_Should not be underlined._ (escaped leading underscore plus a trailing one)

Definitely some inconsistency here.

I'm writing some documentation for my own purposes and will give it to you when I'm done.

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.

johnfound

johnfound

crustyoz

I assume the definition of a strikethrough fragment is that it starts and ends with a dash.

e.g. this is struck through

But this is also handled the same way by the parser and does not have the terminating dash.

I think this is a parser bug.

How does one use a dash in the text as just a dash? Let's see if backslash dash works:

\-This should not be struck through.- Notice that the trailing dash is NOT displayed. I think this is a parser bug.

Can the others be escaped?

Should not be bold. (leading asterisk but no trailing)

\*Should not be bold.* (escaped leading asterisk plus a trailing one)

Should not be underlined. (leading underscore but no trailing)

\_Should not be underlined._ (escaped leading underscore plus a trailing one)

Definitely some inconsistency here.

I'm writing some documentation for my own purposes and will give it to you when I'm done.

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.

crustyoz

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.

Hi johnfound

Sorry for pumping an old thread.

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!

ganuonglachanh

Hi johnfound

Sorry for pumping an old thread.

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.

But well, I have such plans in my To-Do list. 😊