Android-FileBrowser-FilePicker icon indicating copy to clipboard operation
Android-FileBrowser-FilePicker copied to clipboard

Nested block level items break list without blank line after

Open kutetapolu opened this issue 6 years ago • 10 comments

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

kutetapolu avatar Jul 12 '19 11:07 kutetapolu

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

waylan avatar Jul 12 '19 13:07 waylan

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.

JustAPerson avatar Dec 18 '19 09:12 JustAPerson

@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 avatar Jun 30 '20 20:06 waylan

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

CyrilleB79 avatar Jul 09 '21 09:07 CyrilleB79

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.

waylan avatar Jul 09 '21 13:07 waylan

I will fix this bug, just wait

ghost avatar Jun 22 '22 06:06 ghost

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>

dmail00 avatar Dec 12 '23 22:12 dmail00

@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.

waylan avatar Dec 13 '23 13:12 waylan

@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

dmail00 avatar Dec 13 '23 14:12 dmail00

@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.

waylan avatar Dec 13 '23 17:12 waylan