|
ticket id 000055 |
status closed |
priority ??? |
assigned to NOBODY |
Reported by: Ben Thorp Component: |
If you manage to put inconsistent numbers of spaces between the bullet and the list item, you can end up with a paragraph inside your list:
* item 1 (4 spaces)
* item 2 (4 spaces)
* item 3 (5 spaces)
* item 4 (5 spaces)
* item 5 (4 spaces)
Renders like this:
<ul>
<li>item 1 (4 spaces)</li>
<li>item 2 (4 spaces)<p>item 3 (5 spaces)</p>
<p>item 4 (5 spaces)</p>
</li>
<li>item 5 (4 spaces)</li>
</ul>
Rather than:
<ul>
<li>item 1 (4 spaces)</li>
<li>item 2 (4 spaces)</li>
<li>item 3 (5 spaces)</li>
<li>item 4 (5 spaces)</li>
<li>item 5 (4 spaces)</li>
</ul>
It seems to be based around the markdown.TAB_LENGTH (4 in the above example), but doesn't seem to be consistent with what happens on Dingus.
UPDATE As far as I can tell from the code, it's currently doing checks on the spaces after the bullet point, which I would think would be incorrect. A small change to the regular expressions seems to resolve this issue in my original item, although not in my test case, and goes some way to resolving the other list issue from ticket 000053.
# Detect an item (``1. item``). ``group(1)`` contains contents of item.
RE = re.compile(r'^[ ]{0,3}\d+\.[ ]+(.*)')
# Detect items on secondary lines. they can be of either list type.
CHILD_RE = re.compile(r'^[ ]{0,3}((\d+\.)|[*+-])[ ]+(.*)')
# Detect indented (nested) items of either type
INDENT_RE = re.compile(r'^[ ]{4,7}((\d+\.)|[*+-])[ ]+.*')
UPDATE2 Turns out I'm a stupidhead and this is fixed in 2.0.3. Sorry
Resolution
n.a.