Re: [Docutils-users] Additional parsing, error handling and newbie help.

[roger <ro...@co...>]

[
 Not cc:'d to David as a curtesy as he indicated he may not want to
 continue reading this thread.
]
On Mon, 2008-05-05 at 16:02 -0400, David Goodger wrote:
> It seems to me that you're trying to make Docutils conform to your
> application's architecture. 

No. I'm try to understand docutils architecture so I can use it in the
context of my application. Maybe my control flow is backwards  -
but it seems to work at the moment, may be only seems - I don't
know - that was part of what I was hoping to find out.

The only *fixed* part of the architecture my application has is the
input file format - I did however express surprise at the discovery I
might have to write complex extra class to add a smalll feature to
otherwise seemingly working code.

> If you want to use Docutils, study how it
> works and figure out how to use it properly. "Properly" here means via
> the docutils.core module 

I want to use it properly - but I don't understand the architecture
well enough to do what that is. I've read pydoc docutils.core
and I'm none the wiser.

Which is why I asked here I thought I might get some helpful pointers,
not what  "your application is wrong - try again". I can't imagine
custom compound documents are that rare.

> -- either use a Publisher object, or use a
> publish_* convenience function. If you try to short-circuit the
> architecture, you're on you're own.

I didn't know I was short-curcuiting anythdidn'ting - I copied
quicktest.py,
then changed it's single call to parse to multiple calls. Is that really
an unreasonable approach . I fully knew it wasn't the best approach but
wasn't aware it would be considered invalid here.

And thanks thats the first indication I'be had that 
I need to use a publisher object, if the the publish_*
functions aren't good enough.  Which now makes docutils.core
make some sense. 

> I'm sorry, but I don't have time to study your code

I'm not really asking you or anyone else to either, but I realise that
sometimes showing the code is the easiest way to illustrate a point.

I'm sorry you haven't done anything other than point me at 
documentation I have already read and not understood. It might
seem to you guys out there I'm doing something silly - but I really
don't understand what.

But putting that aside, is it true that docutils does not support
incremental parsing? 

I have also asked if I should use a reader class as the PEP you pointed
me at suggested reader classes are a mechanism for compound documents,
and wether they were any existant implementations I could learn
from.  So I'm not sure whether this is using it 'properly' or not,
or where to start - though I have a better idea now. 

Since my last mail I found docutils.utils.Reporter - which looks
like a very handy class to do what I need to do. But I guess they aren't
proper way of doing anything since there not in du.core ether..

Sorry Guys - but this is sinking not waving.

When in comes done to it, all I need to do is pass docutils a
rst document and someway of indicating different parts of the
document have differents sources. I've even got code that
creates this rst document it just isn't able to get that data into
docutils 'properly'. Thinking about it - I cant be calling docutils
properly since diffing it's parsed output shows differences with 
just running the rst output through rst2html. Which I'd be happy
to do if it wan't much harder to errors in the input data (which
force rst errors) that way.

I guess from the tone of both of our email there is exasperation
on both sides -I apologise for anything anyone took to be rude.

Since I'm sure you are trying to be  helpful - and I
assure you I'm not trying to be difficult -  I'm trying to learn but
until this last email I really haven't had any clear example or pointers
on how the library is intended to be called - which is all 
I really wanted in the first place.

TTFN
-- 
roger <ro...@co...>