Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nested block level items break list without blank line after #845

Open
kutetapolu opened this issue Jul 12, 2019 · 10 comments
Open

Nested block level items break list without blank line after #845

kutetapolu opened this issue Jul 12, 2019 · 10 comments
Labels
bug Bug report. confirmed Confirmed bug report or approved feature request. core Related to the core parser code. someday-maybe Approved low priority request.

Comments

@kutetapolu
Copy link

Hi. I did submit this issue previously (#750), but github banned me for no reason whatsoever. I'm reposting it so it won't get lost.

Basically, this:

- item one

    second paragraph of item 1
- item two

Renders as:

<ul>
  <li>
    <p>item one</p>
    <p>second paragraph of item 1
- item two</p>
  </li>
</ul>

Here is the screenshot of previous discussion just in case:

750

@waylan waylan added bug Bug report. confirmed Confirmed bug report or approved feature request. core Related to the core parser code. labels Jul 12, 2019
@waylan
Copy link
Member

waylan commented Jul 12, 2019

Thanks. As the old issue was deleted, we had completely forgotten about it.

@JustAPerson
Copy link

JustAPerson commented Dec 18, 2019

I think I found another case of the same bug.

- a
    hmm

- b
- c
<ul>
  <li>
  <p>a
      hmmm</p>
  </li>
  <li><p>b</p></li>
  <li>c</li>
</ul>

Notice how the line b now is incorrectly wrapped in a <p> tag.

@waylan
Copy link
Member

waylan commented Jun 30, 2020

@JustAPerson that is not related. In fact, that is correct behavior. Babelmark shows two common results, one which is defined in the Commonmark spec and one which follows the original rules. We are in the second group along with the reference implementation. Both agree that b should be wrapped in a <p> tag as the blank line before it forces it to be a loose list item. The difference between the two is that the third item reverts to a tight list in classic Markdown as it is not preceded by a blank line. In contrast, Commonmark applies the loose list to the entire list, not just the items which are adjacent to blank lines. In fact, the Commonmark spec acknowledges that this behavior diverges from classic Markdown.

@waylan waylan added the someday-maybe Approved low priority request. label Jul 1, 2020
@CyrilleB79
Copy link

Hello
I am also impacted by this issue.
Is there any possible work-around in the meantime?

My use case is the following:

A list with items and sub-items:

* First item containing a sub-list and an additional paragraph:

    * First sub-item
    * Second sub-item
    
    Additional paragraph in first item
* Second item

@waylan
Copy link
Member

waylan commented Jul 9, 2021

This is clearly a bug as demonstrated by Babelmark, but the "fix" isn't immediately obvious. Consider the expected behavior of the following examples:

- item one

    second paragraph of item 1
line two of second paragraph of item 1

In that case, the second line of the paragraph does not need to be indented and that is valid. In fact, this is exactly the behavior we are seeing with the original example.

But, shouldn't the hyphen at the start of the line change the behavior? Consider this example:

First line of a paragraph
- second line, not a list item.

Again, we need to ignore the Commonmark implementations and focus on the reference implementation.

Whatever fix we implement needs to maintain the current behavior of the above two examples, but somehow detect that an outdented line starts with a list item marker and treat it differently.

The "workaround" it to add a blank line. Of course, that will wrap the second list item in a <p> tag as well, which is presumably not desired. That said, I would consider it bad form (the sort of thing a linter would complain about) to not have all list items be loose list items if any one is. In other words, because you have one loose list item, you should make all items loose for consistency by adding a blank line between every item. When doing so this issue doesn't matter.

Given the above, finding a fix is not a high priority for me (note the someday-maybe label on this issue). That said, we would certainly be willing to accept a fix if one is provided.

@ghost
Copy link

ghost commented Jun 22, 2022

I will fix this bug, just wait

@dmail00
Copy link

dmail00 commented Dec 12, 2023

Another case that seems to be related. Here the unordered list tag is not generated and it is considered an ordered with paragraphs.

def test_lists() -> None:
    """Ordered followed by unordered creates paragraphs and only an ordered list"""
    markdown_text = """

1. Ordered First
2. Ordered Second


* Unordered First
* Unordered Second

"""
    result = markdown.markdown(markdown_text)
    print(result)


if __name__ == "__main__":
    test_lists()

Output

<ol>
<li>Ordered First</li>
<li>
<p>Ordered Second</p>
</li>
<li>
<p>Unordered First</p>
</li>
<li>Unordered Second</li>
</ol>

@waylan
Copy link
Member

waylan commented Dec 13, 2023

@dmail00 that is not related. In fact, that is expected behavior. If however, you would prefer less surprising behavior, we have included the sane lists extension.

@dmail00
Copy link

dmail00 commented Dec 13, 2023

@waylan Thanks for that info.
Maybe there is a typo on that page

Whereas the default Markdown behavior would be to generate an unordered list.

The code I posted sees extremely close to the example on the page yet generates an ordered list.

Whilst it is no consequence to myself now that I know about that extension, that page also makes no mention of the p tags in the example for default behaviour.

Thanks

@waylan
Copy link
Member

waylan commented Dec 13, 2023

@dmail00 the matter was discussed in detail in #64 (see also #422 and #612). Please, let's not add any more noise to this unrelated issue. If you have an issue with the existing extension, please open a new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Bug report. confirmed Confirmed bug report or approved feature request. core Related to the core parser code. someday-maybe Approved low priority request.
Projects
None yet
Development

No branches or pull requests

5 participants