docutils-users — General discussions, questions, help requests.

Re: [Docutils-users] Removing certain elements from reSTX markup

[David G. <go...@py...>]

Morten W. Petersen wrote:
>> First, why?  What's your use case?  The simplest solution is, just
>> don't use that markup in your documents.  If it's important, make it
>> a policy decision in your organization.
> 
> I'm trying to find a mix of simplified RST that can be used straight
> away, and at most have 4-5 different markups (easily taught), for
> example emphasis, bullet lists, blockquotes and simple tables.

What do you do when the user needs one more construct, that isn't included
in your simplified set?  Personally, I'd rather begin educating with a small
number of core constructs, but using the full parser.  Simultaneously, give
references to the full docs for those who are interested in going further.

We don't teach programming languages or natural languages using limited
subsets.  We begin with simple concepts and build from there.

From PEP 287, Questions & Answers, #2:

   Is reStructuredText *too* rich?

   For specific applications or individuals, perhaps.  In general, no.

   Since the very beginning, whenever a docstring markup syntax has
   been proposed on the Doc-SIG_, someone has complained about the
   lack of support for some construct or other.  The reply was often
   something like, "These are docstrings we're talking about, and
   docstrings shouldn't have complex markup."  The problem is that a
   construct that seems superfluous to one person may be absolutely
   essential to another.

   reStructuredText takes the opposite approach: it provides a rich
   set of implicit markup constructs (plus a generic extension
   mechanism for explicit markup), allowing for all kinds of
   documents.  If the set of constructs is too rich for a particular
   application, the unused constructs can either be removed from the
   parser (via application-specific overrides) or simply omitted by
   convention.

I'd emphasize the final "or simply omitted by convention" as preferable.

> At the same time, I want to remove the ability to mess things up
> ... so that users can
> do whatever they want when not using the agreed upon markups.
>
>> Second, what should the parser do with the markup it ignores?
> 
> Don't touch it, 'pass it on' in other words.

Please consider carefully: would you really be doing your users a service
with this approach?

I think back to when I learned Japanese.  The class spent the first week
learning hiragana, the basic Japanese syllable characters (similar to an
alphabet), so we wouldn't get hooked on using "roma-ji" (roman letters, A-Z)
as a crutch.  When I lived in Japan, I found that people who had learned
Japanese with roma-ji reached a point -- learning written language -- beyond
which it was very difficult to progress, whereas those who learned with
hiragana had a much easier time.

Of course, reStructuredText is a much simpler language, but I believe the
same principles apply.

> (``'' is turned into some sort of hyperlink)

It's an error that's turned into a "problematic" element, with a link to the
diagnostic explanation.  It's an error because of unbalanced
double-backquotes.

>> The parser is not set up for this to be really easy to do, because it
>> hasn't been needed yet.
> 
> If there are more people out there like me, maybe it would be an idea
> to refactor a bit to make parts of docutils more like a 'markup
> parsing framework'?  Make it easier to mix-n-match different
> markups, which could lead to diverse markup 'dialects' of STX;
> diverse enough to be used by common people without screwing
> up, and diverse enough for the syntatic programmer.

I don't think encouraging dialects is a good idea.  It introduces
incompatibilities.  This use case doesn't sufficiently justify such changes
to me.  'Course, patches are always welcome.

-- David Goodger    http://starship.python.net/~goodger

Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv

Re: [Docutils-users] Removing certain elements from reSTX markup

[Morten W. P. <mo...@ni...>]

> First, why?  What's your use case?  The simplest solution is, just 
> don't use that markup in your documents.  If it's important, make it
> a policy decision in your organization.

I'm trying to find a mix of simplified RST that can be used straight
away, and at most have 4-5 different markups (easily taught), for
example emphasis, bullet lists, blockquotes and simple tables.

At the same time, I want to remove the ability to mess things up
(``'' is turned into some sort of hyperlink) so that users can
do whatever they want when not using the agreed upon markups.

> Second, what should the parser do with the markup it ignores?

Don't touch it, 'pass it on' in other words.

> Third, which type of markup do you want to suppress, inline markup or
> block-level markup?

Both, I guess.

> The parser (implemented in module docutils.parsers.rst.states) deals 
> with the two separately and differently.  Block-level markup is
> recognized via an ordered dispatch table; remove the entry for the
> markup you don't want, and it won't be recognized.  Inline 
> markup (class Inliner) is recognized with a large regular expression
> (Inliner.patterns.initial) that's built from a data structure 
> (Inliner.parts), plus a table for standalone/implicit markup (URLs
> etc.; Inliner.implicit_dispatch).  Alter the data structure, rebuild
> and reinstall the regexp, and go from there.  Of course, you should
> work on subclasses or instances so as not to step on toes.

OK, I'll have a look at that.  Again, useful info.  :)

> The parser is not set up for this to be really easy to do, because it 
> hasn't been needed yet.

If there are more people out there like me, maybe it would be an idea
to refactor a bit to make parts of docutils more like a 'markup
parsing framework'?  Make it easier to mix-n-match different
markups, which could lead to diverse markup 'dialects' of STX;
diverse enough to be used by common people without screwing
up, and diverse enough for the syntatic programmer.

> > (without using the :: markup).
> 
> What does this mean?

Something like "making the parser ignore markup without literal
blocks".

Regards,

Morten W. Petersen

Technologies: Zope, Linux, Python, HTML, CSS, PHP
    Homepage: http://www.nidelven-it.no
Phone number: (+47) 45 44 00 69

Re: [Docutils-users] Removing certain elements from reSTX markup

[David G. <go...@py...>]

Morten W. Petersen wrote:
>> What do you mean?  Remove marked-up text from a document, or remove
>> functionality from the parser?
> 
> Remove functionality from the parser, make the parser ignore certain
> elements

First, why?  What's your use case?  The simplest solution is, just don't use
that markup in your documents.  If it's important, make it a policy decision
in your organization.

Second, what should the parser do with the markup it ignores?

Third, which type of markup do you want to suppress, inline markup or
block-level markup?

The parser (implemented in module docutils.parsers.rst.states) deals with
the two separately and differently.  Block-level markup is recognized via an
ordered dispatch table; remove the entry for the markup you don't want, and
it won't be recognized.  Inline markup (class Inliner) is recognized with a
large regular expression (Inliner.patterns.initial) that's built from a data
structure (Inliner.parts), plus a table for standalone/implicit markup (URLs
etc.; Inliner.implicit_dispatch).  Alter the data structure, rebuild and
reinstall the regexp, and go from there.  Of course, you should work on
subclasses or instances so as not to step on toes.

The parser is not set up for this to be really easy to do, because it hasn't
been needed yet.

> (without using the :: markup).

What does this mean?

-- David Goodger    http://starship.python.net/~goodger

Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv

Re: [Docutils-users] Removing certain elements from reSTX markup

[<po...@or...>]

"Morten W. Petersen" <mo...@ni...> writes:

> Hi!
> 
> I'm skimming through the "reStructuredText Markup Specification" and I'm
> wondering how to remove certain elements from the markup, such as
> inline literals.  Any ideas?

Could you be a bit more specific? How would you like to remove them?

* don't allow them in a document in the first place? (I'm not sure how
  you can reduce reST to a subset except by not using parts that you
  don't want to use.)

* don't allow an inline literal to appear in an output file? (Create a
  custom writer that handles inline literals any way you want.)

* remove the inline literal markups (``) from the output? (That
  happens automatically already when the document is read and the tree
  is built.)

* some other way that I'm not understanding (Provide more details.)

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

Re: [Docutils-users] Removing certain elements from reSTX markup

[Morten W. P. <mo...@ni...>]

> Morten W. Petersen wrote:
>> I'm skimming through the "reStructuredText Markup Specification" and
>> I'm wondering how to remove certain elements from the markup, such as
>> inline literals.  Any ideas?
> 
> What do you mean?  Remove marked-up text from a document, or remove
> functionality from the parser?

Remove functionality from the parser, make the parser ignore certain
elements (without using the :: markup).

Regards,

Morten W. Petersen

Technologies: Zope, Linux, Python, HTML, CSS, PHP
    Homepage: http://www.nidelven-it.no
Phone number: (+47) 45 44 00 69

Re: [Docutils-users] Removing certain elements from reSTX markup

[David G. <go...@py...>]

Morten W. Petersen wrote:
> I'm skimming through the "reStructuredText Markup Specification" and I'm
> wondering how to remove certain elements from the markup, such as
> inline literals.  Any ideas?

What do you mean?  Remove marked-up text from a document, or remove
functionality from the parser?

-- David Goodger    http://starship.python.net/~goodger

Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv

[Docutils-users] Removing certain elements from reSTX markup

[Morten W. P. <mo...@ni...>]

Hi!

I'm skimming through the "reStructuredText Markup Specification" and I'm
wondering how to remove certain elements from the markup, such as
inline literals.  Any ideas?

Regards,

Morten W. Petersen

Technologies: Zope, Linux, Python, HTML, CSS, PHP
    Homepage: http://www.nidelven-it.no
Phone number: (+47) 45 44 00 69

RE: [Docutils-users] Multiple html classes per literal block?

[Saunders, G. <gsa...@ea...>]

> -----Original Message-----
> From: David Goodger [mailto:go...@py...]=20
> Sent: March 3, 2003 3:54 PM
> To: Saunders, Graydon; doc...@so...
> Subject: Re: [Docutils-users] Multiple html classes per literal block?
>=20
>=20
> Saunders, Graydon wrote:
> > What I want to do is to have a code example which is included as a=20
> > literal block and which has a range of lines specifed as having a=20
> > different class name from the rest of the block, so it's=20
> > possible to=20
> > highlight some part of the code example as the interesting bit.
>=20
> Not a bad idea.  A directive could fit the bill.  For example::
>=20
>     .. literal::
>        :highlight: 2-3
>=20
>        Here's the literal block, line 1 (first non-blank line).
>        Line numbering would be 1-based, including end-points,
>        so non-geeks could use it too.

Yes.

>        The "highlight" option could take multiple line &
>        range arguments, comma-separated.  Is there
>        a standard for such notation?

Not that I know of.

I'd expect either 2..6,19..28
Or 2-6,10-28

> An alternative would be to number the lines of a literal=20
> block, to allow for textual references.  Something like this::
>=20
>     .. literal::
>        :numbered-lines:
>=20
>        line one
>        line two
>=20
> Would produce something like::
>=20
>     (1)    line one
>     (2)    line two

That seems potentially handy, but it's not a current need.

> > Ideally, one could specify multiple ranges per literal=20
> > block and the=20
> > associated class name extension so example 1 and example 2=20
> > can easily=20
> > have the same kind of highlighting for the same 'notice=20
> > this' things.
>=20
> I'm not following.  What's "associated class name extension"?=20
>  Please explain and provide examples.

Right now, when I use

.. Include:: <foo>
	:literal:

The result is the contents of <foo> in=20
<pre class=3D"literal-block"></pre> tags.

If I've got two different sets of lines marked 'interesting', I'd like
to have them have different class names so I can give them distinct
colours in the stylesheet.

So=20
.. literal::=20
	:highlight: 2-6,10-28

I'd want whatever tags results in the HTML to have
'class=3D"literal-block:', 'class=3D"literal-block-interesting-1"' and
'class=3D"literal-block-interesting-2"' or similar so there's something
for the stylesheet to reference.  Incrementing numbers seems to fit
pretty well with the feel of reStructured Text.

The *next* time there's a literal directive -
.. literal::
	:highlight: 4-12

I'd want the class associated with those nine lines to be
'class=3D"literal-block-interesting-1"'.

If it was
.. Literal::
	:highlight: -,4-12

I'd want the class associated with those nine lines to be
'class=3D"literal-block-interesting-2"'.

That make sense?  The hope is to have examples with consistent
highlighting colours for different kinds of interesting, even when every
kind of interesting isn't present in every example.

> > I don't think that's currently possible; if it is, I'd=20
> > appreciate to=20
> > be told how to do it.
>=20
> Neither are currently possible; they'd require=20
> implementation.  Patches are always welcome!

Unfortunately, I entirely lack the programmer nature.

> > I'm also unsure that it's necessarily an extension you'd care to=20
> > entertain; I'd like to advance strongly that it would be=20
> > very useful=20
> > for anyone trying to build documentation addressing that=20
> > theological=20
> > question of 'why'.
>=20
> I agree that it would be useful.  I'd be "willing to=20
> entertain" quite a bit, if implemented as a directive.  It's=20
> much easier than new syntax.

Well, considering that 'include' is already a directive, I'd have to be
feeling quite unhinged to sugguest a syntax change.

Not feeling that unhinged. :)

Thank you!

Re: [Docutils-users] Multiple html classes per literal block?

[David G. <go...@py...>]

Saunders, Graydon wrote:
> What I want to do is to have a code example which is included as a
> literal block and which has a range of lines specifed as having a
> different class name from the rest of the block, so it's possible to
> highlight some part of the code example as the interesting bit.

Not a bad idea.  A directive could fit the bill.  For example::

    .. literal::
       :highlight: 2-3

       Here's the literal block, line 1 (first non-blank line).
       Line numbering would be 1-based, including end-points,
       so non-geeks could use it too.
       The "highlight" option could take multiple line &
       range arguments, comma-separated.  Is there
       a standard for such notation?

An alternative would be to number the lines of a literal block, to allow for
textual references.  Something like this::

    .. literal::
       :numbered-lines:

       line one
       line two

Would produce something like::

    (1)    line one
    (2)    line two

> Ideally, one could specify multiple ranges per literal block and the
> associated class name extension so example 1 and example 2 can easily
> have the same kind of highlighting for the same 'notice this' things.

I'm not following.  What's "associated class name extension"?  Please
explain and provide examples.

> I don't think that's currently possible; if it is, I'd appreciate to be
> told how to do it.

Neither are currently possible; they'd require implementation.  Patches are
always welcome!

> I'm also unsure that it's necessarily an extension you'd care to
> entertain; I'd like to advance strongly that it would be very useful for
> anyone trying to build documentation addressing that theological
> question of 'why'.

I agree that it would be useful.  I'd be "willing to entertain" quite a bit,
if implemented as a directive.  It's much easier than new syntax.

-- David Goodger    http://starship.python.net/~goodger

Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv

RE: [Docutils-users] Multiple html classes per literal block?

[Saunders, G. <gsa...@ea...>]

> -----Original Message-----
> From: Aahz [mailto:aa...@py...]=20
> Sent: March 3, 2003 1:18 PM
> To: Saunders, Graydon
> Cc: doc...@so...
> Subject: Re: [Docutils-users] Multiple html classes per literal block?
>=20
>=20
> On Mon, Mar 03, 2003, Saunders, Graydon wrote:
> >
> > What I want to do is to have a code example which is included as a=20
> > literal block and which has a range of lines specifed as having a=20
> > different class name from the rest of the block, so it's=20
> possible to=20
> > highlight some part of the code example as the interesting bit.
> >=20
> > Ideally, one could specify multiple ranges per literal=20
> block and the=20
> > associated class name extension so example 1 and example 2=20
> can easily=20
> > have the same kind of highlighting for the same 'notice=20
> this' things.
>=20
> I'd say the best way to deal with this is to create a new=20
> ``highlight_literal`` directive.  See the ``parsed_literal``=20
> directive for ideas.  You'd then need to string together=20
> multiple text sections, but that's fine IMO, much better than=20
> trying to use line numbers.

It's not ok to string together multiple text sections, because the text
sections are code examples which get auto-tested, so they have to be
complete examples.  That's something I don't have any control over.

Re: [Docutils-users] Multiple html classes per literal block?

[Aahz <aa...@py...>]

On Mon, Mar 03, 2003, Saunders, Graydon wrote:
>
> What I want to do is to have a code example which is included as a
> literal block and which has a range of lines specifed as having a
> different class name from the rest of the block, so it's possible to
> highlight some part of the code example as the interesting bit.
> 
> Ideally, one could specify multiple ranges per literal block and the
> associated class name extension so example 1 and example 2 can easily
> have the same kind of highlighting for the same 'notice this' things.

I'd say the best way to deal with this is to create a new
``highlight_literal`` directive.  See the ``parsed_literal`` directive
for ideas.  You'd then need to string together multiple text sections,
but that's fine IMO, much better than trying to use line numbers.
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

Register for PyCon now!  http://www.python.org/pycon/reg.html

[Docutils-users] Multiple html classes per literal block?

[Saunders, G. <gsa...@ea...>]

What I want to do is to have a code example which is included as a
literal block and which has a range of lines specifed as having a
different class name from the rest of the block, so it's possible to
highlight some part of the code example as the interesting bit.

Ideally, one could specify multiple ranges per literal block and the
associated class name extension so example 1 and example 2 can easily
have the same kind of highlighting for the same 'notice this' things.

I don't think that's currently possible; if it is, I'd appreciate to be
told how to do it.

I'm also unsure that it's necessarily an extension you'd care to
entertain; I'd like to advance strongly that it would be very useful for
anyone trying to build documentation addressing that theological
question of 'why'.

Graydon Saunders
gsa...@ea...

Re: [Docutils-users] publish_string, inline XHTML and international characters & settings

[Morten W. P. <mo...@ni...>]

>> Can I create a writer that subclasses / makes use of the HTML writer?
>> How?
>
> The docutils/writers/pep.py writer does just that.  Use the source, 
> Luke! If you write up a how-to doc, I and the next person in your 
> shoes will be very grateful.

Ya, OK.

Created a quick-and-dirty Howto (could also create a diff of
the new code for you). :)

Regards,

Morten W. Petersen

Company Homepage: http://www.nidelven-it.no
Phone number:     (+47) 45 44 00 69

Re: [Docutils-users] publish_string, inline XHTML and international characters & settings

[David G. <go...@py...>]

Morten W. Petersen wrote:
> Can I create a writer that subclasses / makes use of the HTML writer?
> How?

The docutils/writers/pep.py writer does just that.  Use the source, Luke!
If you write up a how-to doc, I and the next person in your shoes will be
very grateful.

-- David Goodger    http://starship.python.net/~goodger

Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv

Re: [Docutils-users] publish_string, inline XHTML and international characters & settings

[Morten W. P. <mo...@ni...>]

>> Second, the published XHTML is a valid document, I only want the body
>> of the XHTML returned, how can I do this?
[...]
> Without a new writer, this isn't possible with the publish_string 
> function. If you have access to the Writer object (it's the .writer 
> attribute of a Publisher object), you can access the individual
> parts of an HTML document.

Can I create a writer that subclasses / makes use of the HTML writer? 
How?

Thanks,

Morten W. Petersen

Company Homepage: http://www.nidelven-it.no
Phone number:     (+47) 45 44 00 69

Re: [Docutils-users] publish_string, inline XHTML and international characters & settings

[David G. <go...@py...>]

Morten W. Petersen wrote:
> I'm trying to use the docutils package to format STX text as XHTML, and
> there's two issues.
>=20
> First, the text contains special characters, like =E6, =F8 and =E5; this
> isn't rendered correctly, as the "a v=E6re" turns into "=C3=A5 v=C3=A6re".

That looks like correct output, using the default output encoding of UTF-8.
If you want a different output encoding, you need to specify it.

> I've figured that one needs to pass a settings objects to the publish_str=
ing
> method with input_encoding set,

Docutils is probably correctly guessing the input encoding, using its
built-in heuristics in docutils.io.Input.decode.  Latin-1 is the final
fall-back if nothing else works.

> but I can't figure out how to create a settings object.  How is that done=
?

If you want to use publish_string, it's easier just to pass a dictionary
containing the settings you're interested in.  For example::

    output =3D docutils.core.publish_string(
        ..., settings_overrides=3D{'input_encoding': 'latin-1',
                                 'output_encoding': 'latin-1'})

> Second, the published XHTML is a valid document, I only want the body
> of the XHTML returned, how can I do this?

This has been discussed but never implemented; see the first two items of
<http://docutils.sf.net/spec/notes.html#html-writer>.  Also, the files in
<http://docutils.sf.net/sandbox/oliverr/ht> may be useful.

Without a new writer, this isn't possible with the publish_string function.
If you have access to the Writer object (it's the .writer attribute of a
Publisher object), you can access the individual parts of an HTML document.
To get access to the Publisher & Writer objects, you'd have to use
lower-level code, which publish_string shields you from.

-- David Goodger    http://starship.python.net/~goodger

Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv

Re: [Docutils-users] image directive and units of measure

[David G. <go...@py...>]

Joachim Koenig-Baltes wrote:
> The docutils directive document states that :height: and :width: are number
> interpreted as pixels:
...
> docbook allows to specify units of measure as in TDG:
...
> So I wonder why there is a fixed interpretation in docutils for these
> measures.

The current implementation is sufficient for HTML output.  It wasn't
designed to handle all the units that DocBook supports.

Short answer: it wasn't needed, therefore wasn't implemented.  If it's now
needed, it can be implemented.

> E.g. for the inclusion of an SVG image into pdf the interpretation
> of pixels is not easy as pointed out in TDG and I would like to be able to
> specify the units of measure as applicable. Could the DTD be adjusted for
> that? The concrete interpretation could be left to the transformations.

It's not simply a matter of adjusting the DTD.  We'd need to settle on
directive syntax (new "unit" option, or tack the units onto the height/width
values?), implement it in code (with error-checking), support it in writers
(how should the HTML writer handle units *other* than pixels?), and update
the docs.  Not a huge task, but it requires thought and some work.

I'll add it to the to-do list, but I don't know when or if I'll get to it.
Ideas and patches are welcome!

-- David Goodger    http://starship.python.net/~goodger

Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv

[Docutils-users] publish_string, inline XHTML and international characters & settings

[Morten W. P. <mo...@ni...>]

Hi!

I'm trying to use the docutils package to format STX text as XHTML, and
there's two issues.  

First, the text contains special characters, like æ, ø and å; this
isn't rendered correctly, as the "a være" turns into "Ã¥ være".  I've
figured that one needs to pass a settings objects to the publish_string
method with input_encoding set, but I can't figure out how to create
a settings object.  How is that done?

Second, the published XHTML is a valid document, I only want the body
of the XHTML returned, how can I do this?

Thank you,

Morten W. Petersen

Company Homepage: http://www.nidelven-it.no
Phone number:     (+47) 45 44 00 69

[Docutils-users] image directive and units of measure

[Joachim Koenig-B. <jo...@cm...>]

Hi,

I'm using docutils in conjunction with the xsl stylesheet for docutils-xml
to docbook-xml conversion posted by Eric Bellot some days ago and have a
question concerning image height and width.

The docutils directive document states that :height: and :width: are number
interpreted as pixels:

> height : integer
>     The height of the image in pixels, used to reserve space or scale
>     the image vertically.
> width : integer
>     The width of the image in pixels, used to reserve space or scale
>     the image horizontally.

docbook allows to specify units of measure as in TDG:

> Units of Measure
> 
> The size of the viewport area and the content area are defined in terms
> of lengths (width and depth).
> 
> Lengths must be expressed as a decimal value followed immediately by an
> optional unit of measure or a percentage. Six and one eight inches, for
> example, must be expressed as 6.125in. It is an error to put a space or
> other punctuation between the decimal value and the unit of measure.
> 
> The following units of measure may be used:
> pt Points (1/72 of an inch)
> cm Centimeters
> mm Millimeters
> in Inches
> pc Picas (1/6 of an inch)
> px Pixels
> em Ems
> 
> If no unit of measure is provided, px is assumed. Note that pixels have
> no universally accepted absolute size and ems are relative units of
> measure. Implementations may define pixel sizes differently and
> stylesheets may or may not be able to determine the current font size
> in order to correctly calculate the absolute size of an em. It is best
> to avoid these units of measure.
> 
> Percetages are expressed as a decimal value followed immediately by a % sign.

So I wonder why there is a fixed interpretation in docutils for these
measures. E.g. for the inclusion of an SVG image into pdf the interpretation
of pixels is not easy as pointed out in TDG and I would like to be able to
specify the units of measure as applicable. Could the DTD be adjusted for
that? The concrete interpretation could be left to the transformations.

Joachim

Re: [Docutils-users] ZReST

[Uwe H. <uh...@st...>]

On Sat, 15 Feb 2003, Richard Jones wrote:

> On Sat, 15 Feb 2003 2:18 am, David Goodger wrote:
> > In the HTML Writer, the <pending> and <substitution_reference> node
> > handlers are set up to raise NotImplementedError.  These nodes should
> > have already been handled by document tree transforms.  The results
> > above seem to indicate that the transforms are not being applied.
> >
> > I don't know anything about Zope.  Can the experts shed some light?
> 
> I'm deep in other stuff at the moment and won't get a chance to look into this 
> any time soon, sorry.
> 
> 
>     Richard
> 
>
 
ZReST.py:

# parse!
document = pub.reader.read(pub.source, pub.parser, pub.settings)
##### This line should solve the little problem ###########
pub.apply_transforms(document)
###########################################################
self.warnings = ''.join(pub.settings.warning_stream.messages)

-uhe

[Docutils-users] WALL STREET LIVE: TGYC Announces Revised Revenues and Earnings.......... eerv

[Laren <Liv...@ao...>]

<p>If you bought into our last recommendation (CIMG) early enough you had an excellent opportunity to make substantial gains (from .90 to 1.65 in just the first day).  Now is your chance to do the same with our newest pick: TGYC.  To find out more go to <a href="http://www.sorensonandassociates.com">Live From the Street</a>.</p>
<p align="center"><img border="0" src="http://www.sorensonandassociates.com/bm01.gif"></p>
<p>If you no longer want to receive information from us just go to 
<a href="mailto:ta...@cs...">ta...@cs...</a>.<p>
&nbsp;

wlvnplloxqnejelbyq

Re: [Docutils-users] title underlines, indented bulleted lists and emacs contrib repeat-last-character

[Beni C. <cb...@te...>]

On 2003-02-17, David Goodger wrote:

> Is the proposed solution to the problems (empty comments) sufficient?
> Such cases *will* arise.  Perhaps a runtime setting, allowing or
> disabling this convenience, would be appropriate.  But that raises
> issues too:
>
>     User A, who writes lists indented (and their config file is set up
>     to allow it), sends a file to user B, who doesn't (and their
>     config file disables indented lists).  The result of processing by
>     the two users will be different.
>
That's really bad.  It means there will be two dialects of reST and you
can't exchange files safely.  If you are going to allow both, then allow
both always.

> It may seem minor, but it adds ambiguity to the parser, which is bad.
>
Agreed.  Lately I'm starting to believe that some source variations belong
in the editor.  [For example, I'm trying to envision a system for
translating python source code into other languages based on identifier
replacement by the editor.  That should work acceptably(?) for both
keywords and the library, even 3-rd party ones.]

Which gave me this idea on handle indented lists (I personally prefer them
indented and perhaps without empty lines): let emacs do it.  All reST
documents on disk retain their current format; emacs' reST mode will have
options to indent lists (only visually), hide empty lines in some
contexts, etc...  Of course somebody has to write this mode and it doesn't
scratch badly enough for me to do so yet :-).

-- 
Beni Cherniavsky <cb...@tx...>

Do not feed the Bugzillas.

[Docutils-users] Blockquotes

[Aahz <aa...@py...>]

On Mon, Feb 17, 2003, Moore, Paul wrote:
>
> Personally, I think that this (indented top-level lists) would be
> useful to add. I nearly always indent top-level lists in raw text, as
> I feel that it makes them far easier to read. Personally, I have very
> little use for the blockquote construct (to the extent that it surprises
> me that it's a core docutils feature - but that's just a matter of
> writing style, I guess). Hence, I wouldn't find the conflict onerous in
> practice. I believe the workaround is perfectly adequate.

I'd be perfectly happy with blockquotes as a directive, but they're a
core feature for me.
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

Register for PyCon now!  http://www.python.org/pycon/reg.html

Re: [Docutils-users] title underlines, indented bulleted listsand emacs contrib repeat-last-character

[Nicola L. <ni...@te...>]

> P.S. Hey, how's that for a slogan: "reST roCKs!"

That's great, so let's extend it:

"reST roCKs, so STiCK with it!"

Is this silly enough? ;^)


-- 
"Python is the absolute best at developing things that take more
than a hour to do, of all the languages I have ever seen, period."
   Laura Creighton

Nicola Larosa - ni...@te...

Re: [Docutils-users] title underlines, indented bulleted listsand emacs contrib repeat-last-character

[<po...@or...>]

"Moore, Paul" <Pau...@at...> writes:

> >> So far, this is my one and only gripe with reST.
> 
> It's certainly the only one of any major significance for me...

You guys just aren't trying hard enough. (Just kidding!!!)

Seriously, since we're all patting Dave & Co. on the back, I'll join
in as well. I just submitted the first chapter of my book to my
publisher on Friday in Word format, and I couldn't have done it
without reST and Aahz's OpenOffice writer. On my to-do list for today
is creating a writer for LinuxFormat magazine. I'd say "reST roCKs!"

Group hug anyone?

P.S. Hey, how's that for a slogan: "reST roCKs!"

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------