Move unicode to LaTeX into a method.
[docutils.git] / BUGS.txt
bloba2f438318a18f6ec9f81d3094ec62742566f3205
1 ================
2  Docutils_ Bugs
3 ================
5 :Author: David Goodger; open to all Docutils developers
6 :Contact: goodger@python.org
7 :Date: $Date$
8 :Revision: $Revision$
9 :Copyright: This document has been placed in the public domain.
11 .. _Docutils: http://docutils.sourceforge.net/
14 Bugs in Docutils?!?  Yes, we do have a few.  Some are old-timers that
15 tend to stay in the shadows and don't bother anybody.  Once in a while
16 new bugs are born.  From time to time some bugs (new and old) crawl
17 out into the light and must be dealt with.  Icky.
19 This document describes how to report a bug, and lists known bugs.
21 .. contents::
24 How To Report A Bug
25 ===================
27 If you think you've discovered a bug, please read through these
28 guidelines before reporting it.
30 First, make sure it's a new bug:
32 * Please check the list of `known bugs`_ below and the `SourceForge
33   Bug Tracker`_ to see if it has already been reported.
35 * Are you using the very latest version of Docutils?  The bug may have
36   already been fixed.  Please get the latest version of Docutils from
37   CVS_ or from the `development snapshot`_ and check again.  Even if
38   your bug has not been fixed, others probably have, and you're better
39   off with the most up-to-date code.
41   If you don't have time to check the latest snapshot, please report
42   the bug anyway.  We'd rather tell you that it's already fixed than
43   miss reports of unfixed bugs.
45 * If Docutils does not behave the way you expect, look in the
46   documentation_ (don't forget the FAQ_!) and `mailing list archives`_
47   for evidence that it should behave the way you expect
49 If you're not sure, please ask on the
50 docutils-users@lists.sourceforge.net [1]_ mailing list first.
52 If it's a new bug, the most important thing you can do is to write a
53 simple description and a recipe that reproduces the bug.  Try to
54 create a minimal document that demonstrates the bug.  The easier you
55 make it to understand and track down the bug, the more likely a fix
56 will be.
58 Now you're ready to write the bug report.  Please include:
60 * A clear description of the bug.  Describe how you expected Docutils
61   to behave, and contrast that with how it actually behaved.  While
62   the bug may seem obvious to you, it may not be so obvious to someone
63   else, so it's best to avoid a guessing game.
65 * A complete description of the environment in which you reproduced
66   the bug:
68   - Your operating system & version.
69   - The version of Python (``python -V``).
70   - The version of Docutils (use the "-V" option to most Docutils
71     front-end tools).
72   - Any private modifications you made to Docutils.
73   - Anything else that could possibly be relevant.  Err on the side
74     of too much information, rather than too little.
76 * A literal transcript of the *exact* command you ran, and the *exact*
77   output.  Use the "--traceback" option to get a complete picture.
79 * The exact input and output files.  Better to attach complete files
80   to your bug report than to include just a summary or excerpt.
82 * If you also want to include speculation as to the cause, and even a
83   patch to fix the bug, that would be great!
85 The best place to send your bug report is to the `SourceForge Bug
86 Tracker`_.  That way, it won't be misplaced or forgotten.  In fact, an
87 open bug report on SourceForge is a constant irritant that begs to be
88 squashed.
90 Thank you!
92 (This section was inspired by the `Subversion project's`__ BUGS__
93 file.)
95 .. [1] Due to overwhelming amounts of spam, the
96    docutils-users@lists.sourceforge.net mailing list has been set up
97    for subscriber posting only.  Non-subscribers who post to
98    docutils-users will receive a message with "Subject: Your message
99    to Docutils-users awaits moderator approval".  Legitimate messages
100    are accepted and posted as soon as possible (a list administrator
101    must verify the message manually).  If you'd like to subscribe to
102    docutils-users, please visit
103    <http://lists.sourceforge.net/lists/listinfo/docutils-users>.
105 __ http://subversion.tigris.org/
106 __ http://svn.collab.net/viewcvs/svn/trunk/BUGS?view=markup
108 .. _CVS: http://sourceforge.net/cvs/?group_id=38414
109 .. _development snapshot: http://docutils.sf.net/#development-snapshot
110 .. _documentation: docs/
111 .. _FAQ: FAQ.html
112 .. _mailing list archives: http://docutils.sf.net/#mailing-lists
113 .. _SourceForge Bug Tracker:
114    http://sourceforge.net/tracker/?group_id=38414&atid=422030
117 Known Bugs
118 ==========
120 Also see the `SourceForge Bug Tracker`_.
122 * The parser doesn't know anything about double-width characters such
123   as Chinese hanza & Japanese kanji/kana.  Also, it's dependent on
124   whitespace and punctuation as markup delimiters, which may not be
125   applicable in these languages.
127 * In text inserted by the "include" directive, errors are often not
128   reported with the correct "source" or "line" numbers.  Perhaps all
129   Reporter calls need "source" and "line" keyword arguments.
130   Elements' .line assignments should be checked.  (Assign to .source
131   too?  Add a set_info method?  To what?)  There's a test in
132   test/test_parsers/test_rst/test_directives/test_include.py.
134 * Explicit targets are sometimes mis-located.  In particular, placing
135   a target before a section header puts the target at the end of the
136   previous section instead of the start of the next section.  The code
137   in docutils.transforms.misc.ClassAttribute could be used to fix
138   this.  (Reported by David Priest.)
140 * Upon reviewing RFC 2396, I see that asterisks are valid URL
141   characters, sometimes actually used.  Beni Cherniavsky found one in
142   mid-November and fixed it by modifying the text.  There's a conflict
143   with emphasis, but backslash escapes should overcome that; they
144   don't though.  I consider it a bug in the parser that escaped
145   asterisks in URLs aren't recognized.  Here's the URL that broke::
147       http://cvs.sf.net/viewcvs.py/*checkout*/emu/speech_tools/scripts/tex_to_images.prl?rev=HEAD
149   We should be able to escape the first asterisk like this::
151       http://cvs.sf.net/viewcvs.py/\*checkout*/emu/speech_tools/scripts/tex_to_images.prl?rev=HEAD
153 * Document title should grow an implicit target.
155 * David Abrahams pointed out that doubly-indirect substitutions have a
156   bug, but only when there's multiple references::
158       |substitute| my coke for gin
159       |substitute| you for my mum
160       at least I'll get my washing done
162       .. |substitute| replace:: |replace|
163       .. |replace| replace:: swap
165   This is tricky.  Substitutions have to propagate back completely.
167 * Another bug from David Abrahams (run with ``rst2html.py --traceback``)::
169       .. [#crtp] See |runtime|
171       foo [#tag_dispatching]_
173       .. [#tag_dispatching] See  |runtime|
175       .. |runtime| replace:: 7__
176       __ runtime.html
178       __ reference/__main.html
180   Change the references.Substitutions tranform's priority from 220 to
181   680, so it happens after reference resolution?  Then we have to deal
182   with multiple IDs.  Perhaps the Substitution transform should remove
183   all IDs from definitions after the first substitution reference is
184   processed.
186 * The last segment ("/fc++") gets dropped from this URL::
188       http://www.cc.gatech.edu/~yannis/fc++
192    Local Variables:
193    mode: indented-text
194    indent-tabs-mode: nil
195    sentence-end-double-space: t
196    fill-column: 70
197    End: