Adjacent ordered and unordered lists merged

[moorereason]

Given the following markdown content:

- First
- Last

1. First
2. Last

blackfriday renders

<ul>
<li>First</li>

<li><p>Last</p></li>

<li><p>First</p></li>

<li><p>Last</p></li>
</ul>

I would expect it to render as:

<ul>
<li>First</li>
<li>Last</li>
</ul>

<ol>
<li>First</li>
<li>Last</li>
</ol>

[dmitshur]

I think this is a problem with Markdown, not with blackfriday. Blackfriday is doing the right thing according to how Markdown suggests that should be parsed (it's not a very precise specification though).

[moorereason]

I haven't looked at the code to see how difficult it would be, but would you accept an optional extension to fix this issue?

[rtfb]

Looking at the surface, it seems like something that's fixable and not interfering with other things, so if you want to give it a go, I would consider it for a merge.

[tianon]

I think this might have broken parsing of nested lists too. Here's some example code that's not rendering properly anymore:

## Run Redmine with a Database Container

Running Redmine with a database server is the recommened way.

1.  start a database container

    -   PostgreSQL

    -   MySQL (replace `--link some-postgres:postgres` with `--link some-mysql:mysql` when running redmine)

2.  start redmine

<p>Running Redmine with a database server is the recommened way.</p>

<ol>
<li>start a database container</li>
</ol>

<pre><code>-   PostgreSQL

-   MySQL (replace `--link some-postgres:postgres` with `--link some-mysql:mysql` when running redmine)
</code></pre>

<ol>
<li>start redmine</li>
</ol>

Here's how GitHub renders that block: (and blackfriday, up until recently)

Run Redmine with a Database Container

Running Redmine with a database server is the recommened way.

1. start a database container

• PostgreSQL
• MySQL (replace --link some-postgres:postgres with --link some-mysql:mysql when running redmine)

2. start redmine

[tianon]

(and the source document for that section is https://github.com/docker-library/docs/blob/d2bdba0e8f201164aab29274692630f8dd9607af/redmine/content.md#run-redmine-with-a-database-container, since the tabs don't translate correctly to a comment in GitHub)

[tianon]

(and a link to our failing markdownfmt which is how we noticed the change: https://travis-ci.org/docker-library/docs/builds/128108377#L173)

[kaushalmodi]

This works:

- First
- Last

<!-- any comment -->

1. First
2. Last

[mdlinville]

I am still seeing this bug, as well as other bugs to do with list handling.

Breaking up two numbered lists with a comment as above does not work (it does work for bullet lists). Here is a reproducer. The second 1. item is rendered as 4.

1.  This is a list item
2.  This is another list item in the same list. The number you use in Markdown
    does not necessarily correlate to the number in the final output. By
    convention, we keep them in sync.
3.  For single-digit numbered lists, using two spaces after the period makes
    interior block-level content line up better along tab-stops.

    <!-- separate lists -->

1.  This is a new list. With Hugo, you need to use a HTML comment to separate two
      consecutive lists.

In addition, nested bullet lists 3 levels deep do not work for me. The triply-nested elements just show up as doubly-nested, at the same level as their parents. Here's a reproducer. The sub-sub-item just shows up as the same level as its parent.

- This is a list item
* This is another list item in the same list
- You can mix `-` and `*`
  - To make a sub-item, indent two spaces.
    - This is a sub-sub-item.
  - Another sub-item.

Finally, list items that contain block-level elements within them render the block-level elements outside of the list item, at the same level as the list's <ul> tag. Here's a reproducer. The paragraph and the code block both show up outside of the list, and the list item after them just starts a new list.

- Bullet lists can have paragraphs or block elements within them.

  Just indent the content to be even with the text of the bullet point, rather
  than the bullet itself.

  ```bash
  ls -l

• And a sub-list after some block-level content

[mdlinville]

I can't seem to edit my comment above, but the final code block is not missing its closing fence. Github is eating it and not closing the markdown block correctly.

[kaushalmodi]

Each of the ox-hugo test pages I post below have a Markdown source link for that test on that page. Look for

---

Breaking up lists

Breaking up two numbered lists with a comment as above does not work (it does work for bullet lists).

It works using that comment hack.

1.  foo1
2.  foo2

<!--listend-->

1.  bar1
2.  bar2

Full test

Here is a reproducer. The second 1. item is rendered as 4.

   3.  For single-digit numbered lists, using two spaces after the period makes
       interior block-level content line up better along tab-stops.

       <!-- separate lists -->

   1.  This is a new list. With Hugo, you need to use a HTML comment to separate two
         consecutive lists.

Why do you have that comment indented?

---

>3 level nested lists

In addition, nested bullet lists 3 levels deep do not work for me.

It works fine if you use 4 spaces to indent each level.

-   L1 -- foo1
-   L1 -- foo2
    -   L2 -- bar1
    -   L2 -- bar2
        -   L3 -- baz1
        -   L3 -- baz2
            -   L4 -- zoo1
            -   L4 -- zoo2
                1.  L5 -- numbered1
                2.  L5 -- numbered2
            -   L4 -- zoo1
            -   L4 -- zoo2
        -   L3 -- baz1
        -   L3 -- baz2
    -   L2 -- bar1
    -   L2 -- bar2
-   L1 -- foo1
-   L1 -- foo2

Full nested list test

Here's a reproducer. The sub-sub-item just shows up as the same level as its parent.

   - You can mix `-` and `*`
     - To make a sub-item, indent two spaces.
       - This is a sub-sub-item.
     - Another sub-item.

Yes, the problem seems to be that you are not using 4 spaces.

---

Paragraphs in lists

Finally, list items that contain block-level elements within them render the block-level elements outside of the list item, at the same level as the list's

tag. Here's a reproducer. The paragraph and the code block both show up outside of the list, and the list item after them just starts a new list.

Below works.

-   Bullet lists can have paragraphs or block elements within them.

    Just indent the content to be even with the text of the bullet
    point, rather than the bullet itself.

    ```shell
    ls -l
    ```

Full test for paragraphs in lists

   - Bullet lists can have paragraphs or block elements within them.
   
     Just indent the content to be even with the text of the bullet point, rather
     than the bullet itself.

I think the problem is that you are not indenting the lists items, paragraphs, etc. by 4 spaces. Compare your snippet with mine, including the white spaces.

Github is eating it and not closing the markdown block correctly.

It's because you wrapped the snippet having:

```bash
..
```

in triple backticks.. If the snippet itself has triple backticks, you need to wrap that in quadruple backticks :P .. like this..

````
```bash
..
```
````

[mdlinville]

OK, so lists should be indented 4 spaces and not the (somewhat standard) 2? How about indenting code blocks by using 4 spaces, like is very standard across Github etc? That would break with this? Does that need like 6 spaces? 8?

In general should we be using 4 spaces to indent, rather than always 2? Where are these "rules" set out? I am trying to actually document this so our users will understand what to do and it's just not "If it's broken try adding another layer of indents!"

[kaushalmodi]

Note that I am not a Go dev.. just someone who happens to use Blackfriday as I generate my websites using Hugo.

---

OK, so lists should be indented 4 spaces and not the (somewhat standard) 2?

No idea. This 4-space indentation rule has worked for me. I don't even write those Markdown files by hand. I have designed an exporter package for Emacs/Org mode that exports Org format files to Markdown for Hugo to process.

How about indenting code blocks by using 4 spaces, like is very standard across Github etc? That would break with this?

Try it out.

Does that need like 6 spaces? 8?

Sorry, I have no idea. The solution I posted though is throughly tested and used many many times in my blog.

In general should we be using 4 spaces to indent, rather than always 2?

Yes, that seems to work, but I am not saying that that's the only rule.

Where are these "rules" set out?

Trial and error, as the Blackfriday devs are utterly useless from the support and maintenance aspect.. I got no support from them. (I respect that they put out this package for everyone to use, but it frustrates to have zero response from them on these issues!)

I am trying to actually document this so our users will understand what to do and it's just not "If it's broken try adding another layer of indents!"

I would say that it was safe to document my examples that I linked in my earlier comment.