Dokuwiki: Code block via indention directly after a table makes follow-on text disappear

[systemofapwne]

Observed behavior
When starting a codeblock via two spaces directly after a table, the content within that codeblock will disappear.

Expected behavior
A table will show and directly afterwards a code block, as when using <code>...</code> directly.

Workaround
Adding a newline directly after the table fixes the issue, but that should not be required.

I appended a minimal working example.

```
====== Unexpected behavior ======

|I am a table|
Code block started by indention of two or more spaces breaks rendering of all text until hitting a newline or a new block

• This text appears again, but is still inside the codeblock, even though we had a new line with no leading spaces before it.
• This list item now is outside the codeblock and renders as expected

====== Equivalent example ======
|I am a table|
Code block directly after table explicitly started with code-tags will work as expected

• Neither of these list items...
• ...will be in the code block and render fine.

====== Workaround ======
|I am a table|

When inserting a blank/new line around the code block, everything seems to work

• Neither of these list items...
• ...will be in the code block and render fine.```

[phy25]

Interestingly:

  code parsed
|Table as p|
  * list parsed
  * list parsed

|Table parsed|
  code disappeared

Also from the parser end, code disappeared is parsed as regular p_open. Maybe I should look at the handler part.

[alexgearbox]

@systemofapwne
IMHO. This is a feature, not a bug.

[phy25]

Well I think the fact that the code block disappears sounds like a bug to me. From the actual parsing result, I noticed

    [10] => Array
        (
            [0] => tablecell_close
            [1] => Array
                (
                )

            [2] => 29
        )

    [11] => Array
        (
            [0] => tablerow_close
            [1] => Array
                (
                )

            [2] => 50
        )

which means the preformatted block is lost between tablecell_close and tablerow_close. If I use the unittest "simple" parser it's not happening.

Update: still looking at it, but if I removed preformatting from $PARSER_MODES['protected'] it is working, so it should be about the protected behavior

[phy25]

• Why code works? ParserMode\Code has a getSort() number larger than Table, so it won't be triggered before matching Table's exit pattern.
• Why listblock works? ListBlock is not in the $allowedModes of ParserMode\Table as a container so it won't be triggered.
• Why preformatted breaks? It has a lower sort number than ParserMode\Table and is allowed inside table.

I don't think preformatted should be allowed in the table (it does not make sense since it requires spaces at the beginning of the line, and <code> works better in the table). The code that defines this hasn't been touch for 15 years but I think there is a need to move preformatted out of protected mode group.

A reference:

    // containers are complex modes that can contain many other modes
    // hr breaks the principle but they shouldn't be used in tables / lists
    // so they are put here
    'container' => array('listblock', 'table', 'quote', 'hr'),

Can preformatted be used in a list (I don't think so)? If no, then we can move preformatted to the container group. However I am not sure if this will break other things.

[phy25]

Forgot something:

• Why is that preformatted block disappearing? Because it is regarded as something at the end of the line without a column closing | so it gets removed by the table.
• Why having a new line between table and preformatted block works? The \n after the table is closing the table, and the other format needs another \n to start. This new line behavior is probably, as @alexgearbox mentioned, a feature.

[KaiMartin]

If there is no newline the following text is dropped with no hint what went wrong and how to return to the expected behavior. From a user point of view this is rather unexpected and annoying when it hits. Therefore I still think this is bug.
At minimum, the documentation of table syntax should be supplemented to include the use of extra new lines.