Nested code blocks in numbered lists have extra whitespace

[SteffenDE]

Hey there!

While looking into phoenixframework/phoenix_live_view#3575, I found what looks like a bug in EarmarkParser:

EarmarkParser.as_ast("""
1. Test

    ```elixir
    def foo
    ```
""")

generates

{:ok,
 [
   {"ol", [],
    [
      {"li", [],
       [
         {"p", [], ["Test"], %{}},
         {"pre", [], [{"code", [{"class", "elixir"}], [" def foo"], %{}}], %{}}
       ], %{}}
    ], %{}}
 ], []}

notice the extra whitespace def foo, which prevents proper diff highlighting.

In ExDoc, one can also see the extra whitespace when selecting:

[SteffenDE]

Hmm I don't know markdown that good, but it looks like I need to indent the block exactly as the previous numbered list item:

EarmarkParser.as_ast("""
1.  Test

    ```elixir
    def foo
    ```
""")

or

EarmarkParser.as_ast("""
1. Test

   ```elixir
   def foo
   ```
"""

works fine. Please just close if this is how it should be :)

[RobertDober]

@SteffenDE
Yeah I was about to test that because I was quite sure this is how Earmark was designed.

However Babelmark tells us, not that you can expect the behavior you expected in the first case too.

So I'll see if I can "fix" this without any troubles in the list indent algorithm (for backwards incompatibility).

If that were the case I would release this with the next version which is scheduled to accompany the release of Elixir 1.18.

Would that delay be a problem for your use case. If not:

Frohe Weihnachten und einen Guten Rutsch

[SteffenDE]

Thanks for looking into it! It’s definitely not urgent, especially since I was able to get the correct highlighting by changing the indentation :)

Have a nice holiday season!

[RobertDober]

I'll probably not fix it, but just for your info

Earmark in general ignores the "One space is not an indent" rule of GFM. Here is another example
from Babelmark wich is rendered as two level 1 headlines, while Earmark does this

iex(1)> md = """
...(1)> # Hello
...(1)>  # World
...(1)> """
"# Hello\n # World\n"
iex(2)> EarmarkParser.as_ast(md)
{:ok, [{"h1", [], ["Hello"], %{}}, {"p", [], [" # World"], %{}}], []}
iex(3)>

does not.

Actually it is not a bad thing to force people to be strict but OTOH if, one day, I release a GFM compatible version this will change anyway, so right now I am just happy that it works for you and that I can put this issue on hold if needed