From: Jason D. <ja...@in...> - 2004-08-01 07:22:48
|
Should this work? (I'm using the latest in CVS.) `|title| <|link|>`_ .. |title| replace:: foo .. |link| replace:: bar The substitutions aren't taking place and I'm not sure if they're supposed to or not (but it would be awesome if they did.) This also doesn't work: *|title|* I get an italicized "|title|" not an italicized "foo". -- Jason |
From: David G. <go...@py...> - 2004-08-01 15:03:04
Attachments:
signature.asc
|
Jason Diamond wrote: > Should this work? Not yet. Nested inline markup is on the to-do list, with high priority. See question 2.15 of the FAQ: <http://docutils.sourceforge.net/FAQ.html>. -- David Goodger <http://python.net/~goodger> |
From: David A. <da...@bo...> - 2004-09-11 21:40:27
|
David Abrahams <da...@bo...> writes: > That said, I'll look into it further to see if I can find out where > those nodes are discarded. Well, I don't even know how to find out where they're created. I'm at a loss. Any clues? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com |
From: Fred L. D. Jr. <fd...@ac...> - 2004-08-01 16:23:14
|
On Sunday 01 August 2004 11:02 am, David Goodger wrote: > Not yet. Nested inline markup is on the to-do list, with high > priority. See question 2.15 of the FAQ: > <http://docutils.sourceforge.net/FAQ.html>. Aren't the code changes needed on a branch already? Since we just had a release, this is the time to get them merged in. I've generally kept out of the nested markup discussion, but I think it's critical that this be done. I"ve missed the functionality many times, and have gone through hoops to do what little can be done even though it takes more markup to do something less flexible than general support for nested markup would allow. Support for nested markup is really important. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> |
From: Felix W. <Fel...@gm...> - 2005-08-29 14:51:45
|
David Abrahams wrote: > This thread: http://thread.gmane.org/gmane.text.docutils.devel/2130 > ends with a desperate plea for someone who understands the deepest > guts of docutils to analyze something specific Mmh. Can you ask more specific questions, please? I have little hints as to what to look for, except that there are some unexpected system_message nodes. And, by the way, it's a lot easier if you ask questions about the *existing* parser (which hasn't changed much since back then, BTW) rather than about your modifications, because otherwise I'd have to understand your modifications. > so that my very substantial work on nested inline markup can be > accepted into the main codebase. It still suffers from some (major?) problems. Try each one of these:: ***foo bar*** *foo `bar* baz` ******* IMPORTANT ******* I'm really not convinced that the current inline parser can be modified (rather than being rewritten) to fully support nested inline markup (as you're trying to do), but I'll concede if I see working code. -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |
From: Mark N. <Mar...@fr...> - 2005-08-29 16:02:17
|
Felix Wiemann wrote: > It still suffers from some (major?) problems. Try each one of these:: > > ***foo bar*** > *foo `bar* baz` > ******* IMPORTANT ******* FWIW, here's what trip produces:: <document source="/tmp/inline.rst"> <paragraph> <strong> <emphasis> foo bar <paragraph> <emphasis> foo \n\ <problematic id="id2" refid="id1"> ` bar baz` <system_message backrefs="id2" id="id1" level="2" line="3" source="/tmp/inline.rst" type="WARNING"> <paragraph> Inline interpreted text or phrase reference start-string without end-string. <paragraph> <strong> <strong> <strong> * IMPORTANT * Is this a reasonable output? --Mark |
From: David G. <go...@py...> - 2004-08-01 16:32:14
Attachments:
signature.asc
|
[Fred L. Drake, Jr.] > Aren't the code changes needed on a branch already? David Abraham's initial work is on the "nesting" branch, but it needs more work. It's not simply a matter of merging it in. > Support for nested markup is really important. I agree. It will take reStructuredText to the next level. BTW, Fred... <http://www.python.org/sf/997050>: your thoughts? -- David Goodger <http://python.net/~goodger> |
From: David A. <da...@bo...> - 2005-08-31 01:40:07
|
Felix Wiemann <Fel...@gm...> writes: > David Abrahams wrote: > >> This thread: http://thread.gmane.org/gmane.text.docutils.devel/2130 >> ends with a desperate plea for someone who understands the deepest >> guts of docutils to analyze something specific > > Mmh. Wow, a response. Let me see if I can dredge up the correct memories of where I was. > Can you ask more specific questions, please? Well, in http://article.gmane.org/gmane.text.docutils.devel/2264 I asked, In order to parse nested inline markup it's sometimes neccessary to do a lot more work, so the fact that more nodes are getting created doesn't really surprise me. Consider the example: Term `with *inline ``text **errors : classifier `with *errors ``too Definition `with *inline ``text **markup errors. I think you can see how that might induce multiple nested parses that wouldn't have to be explored in the case without nesting, right? The point was that the tests I was working with expect particular ids to show up, but I was questioning whether those expectations were appropriate in light of the need to explore and discard parses. And then in http://article.gmane.org/gmane.text.docutils.devel/2265 I asked: > That said, I'll look into it further to see if I can find out where > those nodes are discarded. Well, I don't even know how to find out where they're created. I'm at a loss. Any clues? I was looking for some hints about where to stick breakpoints or print statements in the code, because I couldn't understand how to figure out where the code was creating and/or discarding the extra nodes. > I have little hints as to what to look for, except that there are > some unexpected system_message nodes. And, by the way, it's a lot > easier if you ask questions about the *existing* parser (which > hasn't changed much since back then, BTW) rather than about your > modifications, because otherwise I'd have to understand your > modifications. I don't know what questions I could ask about the existing parser could possibly be useful. I'm trying to understand how to debug it with my modifications in. However, even if you don't understand their details, understanding the *scope* of my modifications isn't all that hard, and IIRC I didn't directly change any of the code that creates or discards nodes. >> so that my very substantial work on nested inline markup can be >> accepted into the main codebase. > > It still suffers from some (major?) problems. Try each one of these:: > > ***foo bar*** > *foo `bar* baz` > ******* IMPORTANT ******* At the moment there's little chance I'll be able to touch that for at least a month, so it would be easier if you'd say what the result is and what you expected. Anyway, I don't know if I'd be surprised by any of those results. IIRC one of the things I was having trouble getting feedback about was what results should be expected for some of these cases. > I'm really not convinced that the current inline parser can be > modified (rather than being rewritten) to fully support nested > inline markup (as you're trying to do), Yes, I keep hearing that. > but I'll concede if I see working code. It's a bit hard to judge whether the code "works" without definitive rulings about what the results of certain tests should be. Anyway, I don't think a parser rewrite is a bad idea; someone should probably go for it. The existing one is a mess. -- Dave Abrahams Boost Consulting www.boost-consulting.com |
From: David A. <da...@bo...> - 2004-08-02 15:40:24
|
David Goodger <go...@py...> writes: > [Fred L. Drake, Jr.] >> Aren't the code changes needed on a branch already? > > David Abraham's initial work is on the "nesting" branch, but it needs > more work. It's not simply a matter of merging it in. Why not? Well, it could be made more readable, but otherwise, why not? If there are things it should do but does not, someone should write tests that it will fail so it can be improved. >> Support for nested markup is really important. > > I agree. It will take reStructuredText to the next level. So what's the hang up? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com |
From: Felix W. <Fel...@gm...> - 2005-08-29 18:12:46
|
Mark Nodine wrote: > Felix Wiemann wrote: > >> Try each one of these:: >> >> ***foo bar*** >> *foo `bar* baz` >> ******* IMPORTANT ******* > > FWIW, here's what trip produces:: > > [snip] > > Is this a reasonable output? Yes, it is indeed reasonable. I'd be interested to poke around and look at the parser code... By the way, if you can't check in trip to Subversion yourself, have you thought about occasionally publishing a tarball? It could be published either via SF.net's release system, by putting it on the BerliOS FTP space (next to the other snapshots), or by checking the tarball contents into SVN (and providing snapshots from SVN). -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |
From: Mark N. <Mar...@fr...> - 2005-08-29 19:17:53
|
Felix Wiemann wrote: > > Mark Nodine wrote: > > > Felix Wiemann wrote: > > > >> Try each one of these:: > >> > >> ***foo bar*** > >> *foo `bar* baz` > >> ******* IMPORTANT ******* > > > > FWIW, here's what trip produces:: > > > > [snip] > > > > Is this a reasonable output? > > Yes, it is indeed reasonable. I'd be interested to poke around and look > at the parser code... > > By the way, if you can't check in trip to Subversion yourself, have you > thought about occasionally publishing a tarball? Good idea. The last released version tracks a snapshot of docutils from over two years ago. I've spent the last 2 weeks trying to bring it up-to-date to pass the regression tests from the 05/08/15 snapshot. Once I'm there, I'll go ahead and put out a tarball. --Mark |
From: Felix W. <Fel...@gm...> - 2005-09-03 20:06:28
|
David Abrahams wrote: > I was looking for some hints about where to stick breakpoints or print > statements in the code, because I couldn't understand how to figure > out where the code was creating and/or discarding the extra > [system_message] nodes. Well, I'd just look at the text of the system_messages and grep... ~/source/docutils/branches/nesting/docutils/docutils/parsers/rst $ grep -nr 'Inline .* start-string without end-string' * states.py:915: 'Inline %s start-string without end-string.' So the answer is, states.py line 915 (in the nesting branch). That's only answering that specific question and it certainly doesn't give you an overview of the inline parser. I hope it helps nonetheless. For more detailed elaborations on the structure and design of the inline parser, I suggest you try to find out yourself and when you're stuck, you ask David specific questions. >> It still suffers from some (major?) problems. Try each one of these:: >> >> ***foo bar*** >> *foo `bar* baz` >> ******* IMPORTANT ******* > > At the moment there's little chance I'll be able to touch that for at > least a month, so it would be easier if you'd say what the result is > and what you expected. $ echo '***foo bar***' | rst2pseudoxml.py <document source="<stdin>"> <paragraph> <strong> <emphasis>foo bar</emphasis> That's a text node which contains literally "<emphasis>foo bar</emphasis>". Correct would be: <document source="<stdin>"> <paragraph> <strong> <emphasis> foo bar The other two examples ("*foo `bar* baz`" and "******* IMPORTANT *******") just cause a crash ("TypeError: coercing to Unicode: need string or buffer, NoneType found" and "AssertionError: sorry, but this version only supports 100 named groups", resp.). -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |
From: David G. <go...@py...> - 2004-08-05 03:34:16
Attachments:
signature.asc
|
[David Goodger] >> David Abraham's initial work is on the "nesting" branch, but it >> needs more work. It's not simply a matter of merging it in. [David Abrahams] > Why not? The current implementation adds regexp groups for each level of inline markup nesting, unbounded. But there is a built-in limit on the number of regexp groups in Python's "re" module. ISTR that we discussed this, but I may be wrong. > Well, it could be made more readable, but otherwise, why not? Much of the parser code could be made more readable. :-) That isn't really a factor here. > If there are things it should do but does not, someone should write > tests that it will fail so it can be improved. Test added on "nesting" branch. Sorry not to have added one sooner. Test input: """\ *It *is *problematic *when *there *are *many *unmatched *open *tags. *The *recursive *parsing *nature *of *the *current *implementation *means *that *there *is *a *limit *to *the *number *of *possible *unmatched *open *tags. """ The test fails with: AssertionError: sorry, but this version only supports 100 named groups > So what's the hang up? I think the implementation has to be reworked. But I may be wrong; I'd be overjoyed to be proved wrong. -- David Goodger <http://python.net/~goodger> |
From: David A. <da...@bo...> - 2005-09-05 00:29:31
|
Felix Wiemann <Fel...@gm...> writes: > David Abrahams wrote: > >> I was looking for some hints about where to stick breakpoints or print >> statements in the code, because I couldn't understand how to figure >> out where the code was creating and/or discarding the extra >> [system_message] nodes. > > Well, I'd just look at the text of the system_messages and grep... > > ~/source/docutils/branches/nesting/docutils/docutils/parsers/rst $ grep -nr 'Inline .* start-string without end-string' * > states.py:915: 'Inline %s start-string without end-string.' > > So the answer is, states.py line 915 (in the nesting branch). > > That's only answering that specific question and it certainly doesn't > give you an overview of the inline parser. I hope it helps nonetheless. > For more detailed elaborations on the structure and design of the inline > parser, I suggest you try to find out yourself and when you're stuck, > you ask David specific questions. Well, I guess I must be too far away from this now, because I obviously had to understand the inline parser to make my changes. So (after more than a year) I clearly don't remember what problem I was having anymore. >>> It still suffers from some (major?) problems. Try each one of these:: >>> >>> ***foo bar*** >>> *foo `bar* baz` >>> ******* IMPORTANT ******* >> >> At the moment there's little chance I'll be able to touch that for at >> least a month, so it would be easier if you'd say what the result is >> and what you expected. > > $ echo '***foo bar***' | rst2pseudoxml.py > <document source="<stdin>"> > <paragraph> > <strong> > <emphasis>foo bar</emphasis> > > That's a text node which contains literally "<emphasis>foo > bar</emphasis>". Correct would be: Okay, now that's just spooky. How could that be due to a bug in my code? I didn't add any code that generates XML tags! I dimly recall that I *may* have modified some of the XML printing code slightly to make it easier to for me to debug what I was doing, so maybe that's what you're seeing? > <document source="<stdin>"> > <paragraph> > <strong> > <emphasis> > foo bar > The other two examples ("*foo `bar* baz`" and "******* IMPORTANT > *******") just cause a crash ("TypeError: coercing to Unicode: need > string or buffer, NoneType found" Don't know what that one is yet. > and "AssertionError: sorry, but this > version only supports 100 named groups", resp.). Yeah, yeah, I know. As I've said repeatedly, the fix for that one is easy; I just wanted to get the mysteries out of the way first. -- Dave Abrahams Boost Consulting www.boost-consulting.com |
From: David A. <da...@bo...> - 2004-08-05 04:56:47
|
David Goodger <go...@py...> writes: > [David Goodger] > >> David Abraham's initial work is on the "nesting" branch, but it > >> needs more work. It's not simply a matter of merging it in. > > [David Abrahams] > > Why not? > > The current implementation adds regexp groups for each level of inline > markup nesting, unbounded. But there is a built-in limit on the > number of regexp groups in Python's "re" module. ISTR that we > discussed this, but I may be wrong. Yes, we did. > > Well, it could be made more readable, but otherwise, why not? > > Much of the parser code could be made more readable. :-) That isn't > really a factor here. Great. > > If there are things it should do but does not, someone should write > > tests that it will fail so it can be improved. > > Test added on "nesting" branch. Sorry not to have added one sooner. > Test input: > > """\ > *It *is *problematic *when *there *are *many *unmatched *open *tags. > *The *recursive *parsing *nature *of *the *current *implementation > *means *that *there *is *a *limit *to *the *number *of *possible > *unmatched *open *tags. > """ > > The test fails with: > > AssertionError: sorry, but this version only supports 100 named groups Great! > > So what's the hang up? > > I think the implementation has to be reworked. But I may be wrong; > I'd be overjoyed to be proved wrong. Well, it needs some small modifications, but a complete rework is unneccessary. I think it would be reasonably easy to fix it so that there were a bounded number of named groups by making some existing named groups unnamed when new groups are added. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com |
From: David A. <da...@bo...> - 2004-08-05 14:08:45
|
David Abrahams <da...@bo...> writes: >> I think the implementation has to be reworked. But I may be wrong; >> I'd be overjoyed to be proved wrong. > > Well, it needs some small modifications, but a complete rework is > unneccessary. I think it would be reasonably easy to fix it so that > there were a bounded number of named groups by making some existing > named groups unnamed when new groups are added. I just spent some time trying to address this, but there have been quite a few changes to the HEAD that I don't understand, including, it seems, changes to the interpreted text role protocol. I am having trouble merging in the changes so that I can do any testing. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com |
From: David G. <go...@py...> - 2004-08-07 14:55:21
Attachments:
signature.asc
|
[David Goodger] >> I think the implementation has to be reworked. But I may be wrong; >> I'd be overjoyed to be proved wrong. [David Abrahams] > Well, it needs some small modifications, but a complete rework is > unneccessary. I think it would be reasonably easy to fix it so that > there were a bounded number of named groups by making some existing > named groups unnamed when new groups are added. I think it should be possible to implement it without an unbounded number of *any* type of groups. > I just spent some time trying to address this, but there have been > quite a few changes to the HEAD that I don't understand, including, > it seems, changes to the interpreted text role protocol. I am > having trouble merging in the changes so that I can do any testing. You could ignore HEAD for now, and we could do the merge later. -- David Goodger <http://python.net/~goodger> |
From: David A. <da...@bo...> - 2004-08-08 14:57:23
|
David Goodger <go...@py...> writes: > [David Goodger] >>> I think the implementation has to be reworked. But I may be wrong; >>> I'd be overjoyed to be proved wrong. > > [David Abrahams] >> Well, it needs some small modifications, but a complete rework is >> unneccessary. I think it would be reasonably easy to fix it so that >> there were a bounded number of named groups by making some existing >> named groups unnamed when new groups are added. > > I think it should be possible to implement it without an unbounded > number of *any* type of groups. Unless you want to slow things down considerably by implementing the logic for identifying the next bit of inline markup in Python instead of in a regexp, I strongly disagree. Further, I don't see any good reason to adopt that goal. Please let me know if that's a criterion of acceptability for you. If it is, I'm going to give up on this. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com |
From: David G. <go...@py...> - 2004-08-08 18:42:28
Attachments:
signature.asc
|
[David Abrahams] > Unless you want to slow things down considerably by implementing the > logic for identifying the next bit of inline markup in Python > instead of in a regexp, I strongly disagree. Further, I don't see > any good reason to adopt that goal. I think there should be other ways of implementing this within regexps and with a constant number of groups. But either way, it's just an implementation detail. > Please let me know if that's a criterion of acceptability for you. It's not. Working as desired and as advertised are the only criteria. -- David Goodger <http://python.net/~goodger> |
From: David A. <da...@bo...> - 2004-08-08 23:55:46
|
David Goodger <go...@py...> writes: > [David Abrahams] > > Unless you want to slow things down considerably by implementing the > > logic for identifying the next bit of inline markup in Python > > instead of in a regexp, I strongly disagree. Further, I don't see > > any good reason to adopt that goal. > > I think there should be other ways of implementing this within regexps > and with a constant number of groups. But either way, it's just an > implementation detail. Good. > > Please let me know if that's a criterion of acceptability for you. > > It's not. Working as desired and as advertised are the only criteria. OK. Is the "roles" parameter to the current Inliner.__init__ just flotsam? It doesn't seem to be used. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com |
From: David G. <go...@py...> - 2004-08-09 01:18:00
Attachments:
signature.asc
|
[David Abrahams] > Is the "roles" parameter to the current Inliner.__init__ just > flotsam? Yes, it looks like junk code. -- David Goodger <http://python.net/~goodger> |
From: David A. <da...@bo...> - 2004-08-16 10:14:47
|
David Abrahams <da...@bo...> writes: > David Abrahams <da...@bo...> writes: > >>> I think the implementation has to be reworked. But I may be wrong; >>> I'd be overjoyed to be proved wrong. >> >> Well, it needs some small modifications, but a complete rework is >> unneccessary. I think it would be reasonably easy to fix it so that >> there were a bounded number of named groups by making some existing >> named groups unnamed when new groups are added. > > I just spent some time trying to address this, but there have been > quite a few changes to the HEAD that I don't understand, including, > it seems, changes to the interpreted text role protocol. I am having > trouble merging in the changes so that I can do any testing. I've done most of the merge. David G., I'd appreciate it if you'd take a quick look at the test results to see if there are any failures you don't expect in light of nesting support. You have to get states.py and roles.py from the nesting branch. I haven't dealt with the unbounded-number-of-named-groups problem yet. Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com |
From: David A. <da...@bo...> - 2004-08-26 02:12:46
|
David Abrahams <da...@bo...> writes: > David Abrahams <da...@bo...> writes: > >> David Abrahams <da...@bo...> writes: >> >>>> I think the implementation has to be reworked. But I may be wrong; >>>> I'd be overjoyed to be proved wrong. >>> >>> Well, it needs some small modifications, but a complete rework is >>> unneccessary. I think it would be reasonably easy to fix it so that >>> there were a bounded number of named groups by making some existing >>> named groups unnamed when new groups are added. >> >> I just spent some time trying to address this, but there have been >> quite a few changes to the HEAD that I don't understand, including, >> it seems, changes to the interpreted text role protocol. I am having >> trouble merging in the changes so that I can do any testing. > > I've done most of the merge. David G., I'd appreciate it if you'd > take a quick look at the test results to see if there are any > failures you don't expect in light of nesting support. You have to > get states.py and roles.py from the nesting branch. Dave G., any chance you could have a quick look? The error output of all_tests.py is not really all *that* big. > I haven't dealt with the unbounded-number-of-named-groups problem yet. Just waiting for feedback before moving on to produce the key result... -- Dave Abrahams Boost Consulting http://www.boost-consulting.com |
From: David G. <go...@py...> - 2004-08-26 14:00:07
Attachments:
signature.asc
|
[David Abrahams] > Dave G., any chance you could have a quick look? The > error output of all_tests.py is not really all *that* big. Actually, it is pretty big! Perhaps it's my setup though. I tried "cvs up" on my local "nesting" branch, but (of course) it only updated to the latest version on that branch, which aren't in sync with the rest of Docutils. I got "AttributeError: class X has no attribute 'y'" a few times before giving up. I believe the significant files are limited to docutils/parsers/rst/states.py and roles.py, test/test_parsers/test_rst/test_nested_inline_markup.py and test_inline_markup.py, and only they had recent changes merged in. So I got a fresh CVS HEAD checkout and substituted the "nesting" branch for those files. Running test/alltests.py on that produced a slew of failures like this: -: expected +: output <document source="test data"> <paragraph> - <reference refname="ref"> + <reference name="ref" refname="ref"> There's something simple missing somewhere, I'm sure. I don't have time to track it down right now though. There are some failures regarding interpreted text: test_parsers/test_rst/test_interpreted.py: totest['references'][1]; test_parser (DocutilsTestSupport.ParserTestCase) input: :PEP:`-1` -: expected +: output <document source="test data"> <paragraph> <problematic id="id2" refid="id1"> - :PEP:`-1` ? ------ - + -1 test_parsers/test_rst/test_interpreted.py: totest['unknown_roles'][1]; test_parser (DocutilsTestSupport.ParserTestCase) input: `interpreted`:role: -: expected +: output <document source="test data"> <paragraph> <problematic id="id2" refid="id1"> - `interpreted`:role: ? - ------- + interpreted As for nested inline markup itself, some IDs changed -- the "nesting" code must assign a bunch of bogus IDs -- but that's not a biggie. And then, of course, the last test in test_parsers/test_rst/test_nested_inline_markup.py fails with: AssertionError: sorry, but this version only supports 100 named groups Other than that, I didn't see anything significant. -- David Goodger <http://python.net/~goodger> |
From: David A. <da...@bo...> - 2004-08-26 14:56:00
|
David Goodger <go...@py...> writes: > [David Abrahams] > > Dave G., any chance you could have a quick look? The > > error output of all_tests.py is not really all *that* big. > > Actually, it is pretty big! Perhaps it's my setup though. > > I tried "cvs up" on my local "nesting" branch Sorry, I don't know what on my local "nesting" branch means. All you should need to get up-to-date is cd .../parsers/rst cvs up -rnesting states.py roles.py > , but (of course) it only updated to the latest version on that > branch, which aren't in sync with the rest of Docutils. ?? It should be; that was the whole point of my recent checkins, which I'm asking you to test. > I got "AttributeError: class X has no attribute 'y'" a few times > before giving up. I believe the significant files are limited to > docutils/parsers/rst/states.py and roles.py, > test/test_parsers/test_rst/test_nested_inline_markup.py and > test_inline_markup.py, and only they had recent changes merged in. ahhh... I didn't test against the branched tests. I just wanted to know if there were any *unexpected* bugs w.r.t. the HEAD tests. > So I got a fresh CVS HEAD checkout and substituted the > "nesting" branch for those files. Running test/alltests.py > on that produced a slew of failures like this: > > -: expected > +: output > <document source="test data"> > <paragraph> > - <reference refname="ref"> > + <reference name="ref" refname="ref"> > > There's something simple missing somewhere, I'm sure. Looks like there's something simple added somewhere. > I don't have time to track it down right now though. > > There are some failures regarding interpreted text: > > test_parsers/test_rst/test_interpreted.py: > totest['references'][1]; test_parser > (DocutilsTestSupport.ParserTestCase) > input: > :PEP:`-1` > > -: expected > +: output > <document source="test data"> > <paragraph> > <problematic id="id2" refid="id1"> > - :PEP:`-1` > ? ------ - > + -1 Hmm, OK. Will look. > test_parsers/test_rst/test_interpreted.py: > totest['unknown_roles'][1]; test_parser > (DocutilsTestSupport.ParserTestCase) > input: > `interpreted`:role: > > -: expected > +: output > <document source="test data"> > <paragraph> > <problematic id="id2" refid="id1"> > - `interpreted`:role: > ? - ------- > + interpreted > > As for nested inline markup itself, some IDs changed -- the > "nesting" code must assign a bunch of bogus IDs Are ids supposed to be stable? What do they mean? > -- but that's not a biggie. And then, of course, the last test in > test_parsers/test_rst/test_nested_inline_markup.py fails with: > > AssertionError: sorry, but this version only supports 100 > named groups Expected. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com |