1. Bitbucket
  2. Public Issue Tracker
  3. master
  4. Issues


Issue #2622 closed

RST renderer does not handle ordered lists correctly (BB-1470)

created an issue

Created a simple readme in RST in which I use reStructuredText's auto-numerated lists support: {{{

. item1

. item2

. item3

}}} However, instead of getting the result I have using docutils and sphinx: {{{ 1. item1 2. item2 3. item3 }}} I get: {{{ 1.





item3 }}} (including the weird spacings)

Comments (3)

  1. masklinn reporter
    • changed status to open

    That doesn't sound or look correct: I was under the impression that it was possible to specify an RST file type via the -*- syntax -*- mark in a text file, and I'm pretty sure Creole has no knowledge of RestructuredText directives such as .. warning or rst code blocks (:: prefix and 4-space indents), or rst footnotes.

    And indeed I have three different examples of bitbucket mostly correctly rendering RST readme files on the project's source page:

    • a README.rst file containing complex formatting (various titles, footnotes, directives and code blocks)
    • a README file which has a much simpler structure (a pair of titles and a definition list), but uses the -*- restructuredtext -*- type tag to be recognized as such by BB
    • a README file of intermediate complexity, but one which uses ordered list and exposes the bug I described above

    Bitbucket does not interpret arbitrary RST files (which is what #2288 is about), but it most definitely seems to interpret README* files at a repository root, knowing them either via their extension or via a type tag.

    I'm removing the dupe marking, as I really don't think it applies: this bug is mostly about styling (the markup generated looks correct).

    Furthermore, I performed one more due diligence check: the bug only seems present in older Gecko (and maybe in MSIE, not sure): I have it using Camino (my usual web browser) which I believe is based on Firefox 3.0's Gecko, but neither Firefox 3.6 nor Safari 5 expose an incorrect behavior.

    So this definitely looks like an issue in BB's CSS triggering a bug in Gecko 1.9.0 (and maybe 1.9.1 as well, that's Firefox 3.5's Gecko, and I don't have FF3.5 on my machine anymore).

  2. Log in to comment