▄▄             ▄▄▄  ▄▄▄ Power
█  █ ▄▄▄▄ ▄▄▄▄▄ █  █ █  █
█▄▄█ █▄▄▄ █ █ █ █▀▀▄ █▀▀▄
█  █ ▄▄▄█ █ █ █ █▄▄▀ █▄▄▀

Login
Register
/ ad amd64 asm asmbb best bugs chat common debian deck design dll email fast fossil friendly gamedev heap help hiawatha incredible interop learning libfresh links linux meme meta.http-equiv money neo nginx numbers orly os outage pass password programmers programming resources script.alert.xss secret seo skins sodom source sourcecode support test work xss игнат котики парола русский тест уеб.програмиране хабр.наполеон
Categories Thread list

Minor parser errors with formatting symbols

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.

    AsmBB v2.4 (check-in: 8bc9b47fcf53ebbd); SQLite v3.25.0 (check-in: 5a954533edbde58a);

    ©2016..2018 John Found; Licensed under EUPL.
    Powered by Assembly language
    Created with Fresh IDE

    Icons are made by Egor Rumyantsev, vaadin and icomoon from www.flaticon.com