Сode bbcode must support recursion about sceditor

[samclarke]

Thanks for reporting!

I've just been loking into how FluxBB handles the ambiguity of parsing the code tags. It seems to do it by requiring the same number of opening and closing code tags.

So FluxBB can't handle:

a[code]b[code]c[/code]d

or

a[code]b[/code]c[/code]d

but can handle:

a[code]b[code]c[/code]d[/code]e

It also looks like other BBCode parsers follow current editor behaviour so this would have to be configurable and default to the current behaviour.

One issue with implementing this is what should the editor do with the ambiguous examples? It has to convert them to something as it can't really show an error like FluxBB.

It could:

• Add the missing closing code tag to the end which would also mean FluxBB can parse it.
• Assume the last closing code tag is the matching one and use that. This would create BBCode FluxBB can't parse but would avoid modifying the BBCode when switching between source and WYSIWYG modes.
• Bail and show the unparsed BBCode, only converting line breaks and spaces. This would cause any whitespace preserved by [code], like tabs, to either be lost or converted to spaces as WYSIWYG doesn't preserve whitespace outside of code tags.

Also, if in WYSIWYG mode someone enters only an opening or closing code tag inside a code block, what should the editor convert it to? Should it generate the ambiguous BBCode or should it automatically insert the missing opening/closing tag?

Marking this as a feature rather than a bug as the current behaviour matches other parsers and this would be a new option.