RFC: Interpreting BBCode inside [code] blocks

[bttrx]

Hi!

At https://www.bttr-software.de/forum/forum_entry.php?id=16141 we noticed a missing [i] in the output for a Pascal code line.

I think, this is how mlf always worked, but do we want to keep that behaviour also for [code] blocks?

Of course, not interpreting BBCode anymore would make existing postings with [code] blocks relying on that feature look ugly. One would have spurious [i][/i] or [b][/b]. "Conversion" by removing those BBCodes during update is no option, I think, because it would change the meaning of the posting.

But here is an example about a possible conversion. The idea is to break the code block into 3 parts, i.e., interrupt the code block right before a b/d/e or other BBCode tag. Then process the b/d/e/... tag and put a new [code] block inside. Afterwards continue with the previous code block.

• Existing posting: [code]for n:=1 to ord(s[0]) [i]do[/i] putc(s[n]);[/code]
• After conversion: [code]for n:=1 to ord(s[0]) [/code][i][code]do[/code][/i][code] putc(s[n]);[/code]

It looks the same to the viewer, although it's technically different.

Robert

[Helmut01]

Hi Robert & all,

At https://www.bttr-software.de/forum/forum_entry.php?id=16141 we noticed a missing [i] in the output for a Pascal code line.

I think, this is how mlf always worked, …

Correct. Since in my forum only registered users can post and this one is an internal category I quote it here (October 2013): The subject line is “Posting R-code: avoid [i]”

Dear all,

if you post R-code avoid the index-variable i in loops. The forum’s scripts will interpret it as the BBCode for italic formating. Please use j, k, l, … instead.

PS: Other characters to avoid as index-variables: b, o, s, u.

… but do we want to keep that behaviour also for [code] blocks?

If avoidable, no. Annoyed me for ages.

But here is an example about a possible conversion. The idea is to break the code block into 3 parts, i.e., interrupt the code block right before a b/d/e or other BBCode tag. Then process the b/d/e/... tag and put a new [code] block inside. Afterwards continue with the previous code block.

• Existing posting: [code]for n:=1 to ord(s[0]) [i]do[/i] putc(s[n]);[/code]
• After conversion: [code]for n:=1 to ord(s[0]) [/code][i][code]do[/code][/i][code] putc(s[n]);[/code]

It looks the same to the viewer, although it's technically different.

Looks good. I tried it some years ago but ended up with regexes  – which are not my thing – and gave up. :-(

Alfie

[auge8472]

Ok, I don't know, if I understood the problem. So I have to ask.

There is the sequence [i] in a posted code fragment and the forum interprets it as <i> outside but also inside a code block?

[Helmut01]

Ok, I don't know, if I understood the problem. So I have to ask.

There is the sequence [i] in a posted code fragment and the forum interprets it as <i> outside but also inside a code block?

[i] inside a code block is left as it is if there is no other [i][/i] in the following text. If there is one, it is stripped and italics turned on, invalid HTML. BTW, there is a side-effect (perhaps only in my code). If a line ends with a pair of square brackets (even if no text is in between), followed by another paragraph the <br> is suppressed in the HTML and the text continues on the same line. If you still have your credentials, see it here.

[auge8472]

Ah, I think, I understand the problem. The regular expression finds a [i] and a [/i] and makes them a pair of <i>…</i>. Because the parser code is not a real parser, that would respect nesting rules, the HTML breaks because of wrong nesting. Correct?

If, then we need a BB-code-parser. One that gets updates and that is understandeable.

[Helmut01]

[…] Because the parser code is not a real parser, that would respect nesting rules, the HTML breaks because of wrong nesting. Correct?

Correct.

If, then we need a BB-code-parser. One that gets updates and that is understandeable.

Yes and yes.

[auge8472]

I think, I found a solution. The library …

• … gets updates (every when and then), …
• … does work with the later PHP-5-versions (it states PHP 5.3 but that seems to be wrong meanwhile (see release note for 1.4.0) while several other libs I found dropped support of PHP 7.2(!) in their newer versions, …
• … allows to create new, own BB-codes, …
• … respects nesting rules, …
• … and last but not least it makes it possible to exclude content of BB-codes from parsing (that's what we need for [code] and [inlinecode] (or however we name it at the end)).

See therefore the example I made in my testing area [1]. You can see there the following pseudo code $variable[i] = 1; as code block and as inline code.

The only thing I don't like is the presence of the many <br />, but that's a problem we have independent from the library (adapted the old code from the forum_entry.php line 157 ff.).

[1]: I'll remove the link in a few days.

[Helmut01]

I think, I found a solution. The library …

Looks interesting.

• … does work with the later PHP-5-versions (it states PHP 5.3 but that seems to be wrong meanwhile (see release note for 1.4.0)

Yep. 5.6+

while several other libs I found dropped support of PHP 7.2(!) in their newer versions, …

Crazy.

See therefore the example I made in my testing area [1]. You can see there the following pseudo code $variable[i] = 1; as code block and as inline code.

Looks good.

The only thing I don't like is the presence of the many <br />, but that's a problem we have independent from the library

Yes. I don’t see how to get around that. If we add the library:

• Change the minimum requirements from php 5.2 to 5.6
• Add the MIT (2011) license

[auge8472]

Meanwhile I poked around in the issue section and I have to test several serious issues before I decide to use the lib or not.