Recent changes to bugs

Embedded URIs don't work as advertised

Charlie Clark — Mon, 30 Jul 2007 21:21:01 -0000

Hi,

can't find this in any of the submissions. I really like ReST and use it on a website in preference to HTML. However, handling URLs can be a problem as people usually want to work with anonymous URLs such as <a href="someurl.com">click here</a>

While explicit use of anonymous targets works fine, embedded URLs do not. According to the documentation the following should work:

`RFC 2396 <http://www.rfc-editor.org/rfc/rfc2396.txt>`__ and `RFC
2732 <http://www.rfc-editor.org/rfc/rfc2732.txt>`__ together
define the syntax of URIs.

It does not work. Instead it raises the following error:

Inline interpreted text or phrase reference start-string without end-string.

I can't why the parser is raising this error.
` is the start string
and
`__ in the end string so this should be complete

setup.py install fails silently

Jeremy Hylton — Tue, 02 Apr 2002 22:22:51 -0000

I did a fresh cvs checkout of restructuredtext. I ran
setup.py install. It made the usual distutils noises,
but it didn't leave any packages in my site-packages
directory.

It created dps and dps/parsers, but neither had an
__init__.py. Under dps/parsers it installed
dps/parsers/restructuredtext and that directory had an
__init__.py -- but no way to get it without its parents
being packages too.

XML entities

Paul Wright — Mon, 20 Aug 2001 13:51:20 -0000

The special characters ampersand, quotes and angle
brackets aren't turned into the relevant XML entities
in the XML output. This means that XML parsers (like
the one in IE) barf on the output.

I'm using ActiveState's ActivePython 2.0 under Win32,
if that makes a difference.

messy closing of inline literals

Garth T Kidd — Wed, 25 Jul 2001 05:15:35 -0000

Non-whitespace immediately after the closing quotes of
an inline literal suppresses recognition of the
literal. The parser doesn't crash, but it does
complain.

Example::

``d``c foo

Result (lightly wrapped)::

<document>
<paragraph>
``d``c foo
</paragraph>
<system_warning level="1">
<paragraph>
Inline literal start-string without
end-string at line 1.
</paragraph>
</system_warning>
</document>

I think the parser should accept the inline literal
without complaint, but will settle for it accepting
the inline literal *and* complaining about the lack of
whitespace.

This is a good candidate for an *anything but this*
test case. :)

text after interpreted breakage

Garth T Kidd — Sat, 21 Jul 2001 09:07:35 -0000

The following breaks the parser::

`vase`:hammer

This doesn't::

`vase`: hammer

docstrings

Garth T Kidd — Sat, 21 Jul 2001 05:54:30 -0000

Self-evident:

* We need docstrings.

Not as self-evident:

* Since __version__ is a release version number,
updated manually, we can't put ``$Revision$``
in it. On the other hand, it *is* very handy
to be able to figure out which revision of the
parser you're using -- especially when you want
to submit a bug for it.

I propose using either or both of the following
in modules::

__revision__ = """$Revision$"""

__id__ = """$Id$"""

refactor tests

Garth T Kidd — Sat, 21 Jul 2001 05:40:28 -0000

``test_states.py`` is 2607 lines and counting. I
suspect it's appropriate to:

* put the test suite into its own module,
* split it up into multiple files within that
module,
* have the module's __init__.py export an
appropriate "test everything" function, and
* create a stub test script in ``restructuredtext/``
that does nothing but parse command line arguments
and then call (wait for it)
``dps.parsers.restructuredtext.testsuite.test_all()
``.

need new test types

Garth T Kidd — Sat, 21 Jul 2001 05:33:25 -0000

At the moment we have only one type of test:

**Expect this**:
Pass if, and only if, the parser produces the
appropriate output from the supplied input.

Added when either

* someone has verified that the parser generates
the appropriate output from the supplied input,
and wants to make sure it stays that way, or
when

* someone knows that the parser *should* generate
the appropriate output from the supplied input.

We could probably do with additional types of test:
[1]_

**Don't crash**:
Pass if the parser doesn't crash when parsing
the supplied input.

Added when someone discovers input that crashes
the parser.

Any passed tests of this type should be changed
into *expect this* tests. If that hasn't been
done, either people are falling behind or nobody
has figured out what the expected output should
be yet.

**Expect anything but this**:
Pass if the parser doesn't generate the supplied
inappropriate output from the input.

Added when the parser is generating bogus output,
but the expected output isn't known yet (presumably
because the error text hasn't been determined).

.. _[1] The need is especially strong during these
early days when both the parser and the spec are
under flux.

bad footnote labels not caught

Garth T Kidd — Sat, 21 Jul 2001 05:18:46 -0000

The following constructs break the parser rather than
generate an error::

.. _[foot label with spaces] text

.. _[*footlabelwithmarkup*] text

I tripped over this one whilst checking to see whether
leading underscores on a footnote label were an
acceptable way of indicating that the rendered label
(and references to it) should be automatically
numbered.