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

Re: [Docutils-users] broken ..epigraph in XeTeX?

[Matěj C. <mc...@ce...>]

On 2017-02-04, 20:26 GMT, Alan G. Isaac wrote:
> Is this another abuse of the ``quote`` environment
> to accomplish indentation?  If so, this again
> compromises the ability to separately style
> quotes and other content (in this case, epigraphs).

OK, so what should I do?

> Note that the ``changepage`` package provides ``adjustwidth``.
> E.g., one could define
> \newenvironment{DUepigraph}%
> {\begin{adjustwidth}{2cm}{}}%
> {\end{adjustwidth}}

How can I redefine already existing environment? In 
docutils.conf?

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ce...
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
It is the mark of an educated mind to be able to entertain
a thought without accepting it.
  -- Aristotle

Re: [Docutils-users] broken ..epigraph in XeTeX?

[Guenter M. <mi...@us...>]

On 2017-02-04, Alan G. Isaac wrote:
> On 2/4/2017 11:51 AM, Matěj Cepl wrote:
>>     \begin{quote}
>>     \DUrole{epigraph}{
>>     Co je nejvyšším cílem člověka?

>>     Nejvyšším cílem člověka je oslavovat Boha a věčně se z Něj
>>     radovat.
>>     \nopagebreak

>>     \raggedleft —Westminsterský katechismus, 1647
>>     }
>>     \end{quote}



> Is this another abuse of the ``quote`` environment
> to accomplish indentation?

No. See the description of the "epigraph" directive.

Docutils converts it to 

    <block_quote classes="epigraph">

and currently handling of block-quotes and some other environments with
classes is broken. 

This will be fixed soon.

> If so, this again compromises the ability to separately style quotes
> and other content (in this case, epigraphs).

Not if the class arguments are handled correctly.

> Note that the ``changepage`` package provides ``adjustwidth``.
> E.g., one could define
> \newenvironment{DUepigraph}%
> {\begin{adjustwidth}{2cm}{}}%
> {\end{adjustwidth}}

> Other default formatting could be added as desired.
> This approach would allow authors to readily modify
> the ``epigraph`` environment (with ``renewenvironment``)
> without interfering with other environments.

> The ``quote`` environment is for (one paragraph) quotes.
> It is not a general indentation facility.
> https://en.wikibooks.org/wiki/LaTeX/Paragraph_Formatting#Quoting_text

Both "quote" and "quotation" provide for multiple paragraphs.
(Just try it.)

The error originates in the \DUrole definition with \providecommand*,
the star makes this check for paragraph breaks in the argument.


Patch attached.

Günter

Dir: docutils-svn/docutils/docutils/writers/latex2e/

Index: __init__.py
===================================================================
--- __init__.py	(Revision 8020)
+++ __init__.py	(Arbeitskopie)
@@ -494,6 +494,7 @@
 PreambleCmds.align_center = r"""
 \makeatletter
 \@namedef{DUrolealign-center}{\centering}
+\@namedef{DUclassalign-center}{\centering}
 \makeatother
 """
 
@@ -512,6 +513,15 @@
 % dedication topic
 \providecommand{\DUtopicdedication}[1]{\begin{center}#1\end{center}}"""
 
+PreambleCmds.DUclass = r"""
+% class handling for environments (block-level elements)
+% \DUclass{#1} tries \DUrole#1
+\providecommand{\DUclass}[1]{%
+  \ifcsname DUclass#1\endcsname%
+    \csname DUclass#1\endcsname%
+  \fi%
+}"""
+
 PreambleCmds.error = r"""
 % error admonition title
 \providecommand*{\DUtitleerror}[1]{\DUtitle{\color{red}#1}}"""
@@ -1568,6 +1578,19 @@
             labels.insert(0, '\\phantomsection')
         return labels
 
+    def insert_DUclass_macros(self, node):
+        for cls in node['classes']:
+            if cls == 'align-center':
+                self.fallbacks['align-center'] = PreambleCmds.align_center
+            if cls.startswith('language-'):
+                language = self.babel.language_name(cls[9:])
+                if language:
+                    self.babel.otherlanguages[language] = True
+                    self.out.append('\\selectlanguage{%s}%\n' % language)
+            else:
+                self.fallbacks['DUclass'] = PreambleCmds.DUclass
+                self.out.append('\\DUclass{%s}%%\n' % cls)
+
     def push_output_collector(self, new_out):
         self.out_stack.append(self.out)
         self.out = new_out
@@ -1631,12 +1654,9 @@
 
     def visit_block_quote(self, node):
         self.out.append( '%\n\\begin{quote}\n')
-        if node['classes']:
-            self.visit_inline(node)
+        self.insert_DUclass_macros(node)
 
     def depart_block_quote(self, node):
-        if node['classes']:
-            self.depart_inline(node)
         self.out.append( '\n\\end{quote}\n')
 
     def visit_bullet_list(self, node):
@@ -1644,12 +1664,9 @@
             self.out.append( '%\n\\begin{list}{}{}\n' )
         else:
             self.out.append( '%\n\\begin{itemize}\n' )
-        # if node['classes']:
-        #     self.visit_inline(node)
+        self.insert_DUclass_macros(node)
 
     def depart_bullet_list(self, node):
-        # if node['classes']:
-        #     self.depart_inline(node)
         if self.is_toc_list:
             self.out.append( '\n\\end{list}\n' )
         else:
@@ -1813,6 +1830,7 @@
 
     def visit_definition_list(self, node):
         self.out.append( '%\n\\begin{description}\n' )
+        self.insert_DUclass_macros(node)
 
     def depart_definition_list(self, node):
         self.out.append( '\\end{description}\n' )
@@ -2093,11 +2111,11 @@
         if 'start' in node:
             self.out.append('\\setcounter{%s}{%d}\n' %
                             (counter_name,node['start']-1))
+        self.insert_DUclass_macros(node)
         #     ## set rightmargin equal to leftmargin
         #     self.out.append('\\setlength{\\rightmargin}{\\leftmargin}\n')
 
 
-
     def depart_enumerated_list(self, node):
         if len(self._enumeration_counters) <= 4:
             self.out.append('\\end{enumerate}\n')
@@ -2130,6 +2148,7 @@
         if self.out is not self.docinfo:
             self.fallbacks['fieldlist'] = PreambleCmds.fieldlist
             self.out.append('%\n\\begin{DUfieldlist}\n')
+        self.insert_DUclass_macros(node)
 
     def depart_field_list(self, node):
         if self.out is not self.docinfo:
@@ -2163,6 +2182,7 @@
             self.out.append('\n\\begin{figure}\n')
         if node.get('ids'):
             self.out += self.ids_to_labels(node) + ['\n']
+        self.insert_DUclass_macros(node)
 
     def depart_figure(self, node):
         self.out.append('\\end{figure}\n')
@@ -2391,14 +2411,9 @@
                              '\\begin{DUlineblock}{\\DUlineblockindent}\n')
         else:
             self.out.append('\n\\begin{DUlineblock}{0em}\n')
-        if node['classes']:
-            self.visit_inline(node)
-            self.out.append('\n')
+        self.insert_DUclass_macros(node)
 
     def depart_line_block(self, node):
-        if node['classes']:
-            self.depart_inline(node)
-            self.out.append('\n')
         self.out.append('\\end{DUlineblock}\n')
 
     def visit_list_item(self, node):
@@ -2576,6 +2591,7 @@
         self.fallbacks['_providelength'] = PreambleCmds.providelength
         self.fallbacks['optionlist'] = PreambleCmds.optionlist
         self.out.append('%\n\\begin{DUoptionlist}\n')
+        self.insert_DUclass_macros(node)
 
     def depart_option_list(self, node):
         self.out.append('\n\\end{DUoptionlist}\n')
@@ -2731,6 +2747,7 @@
         self.requirements['color'] = PreambleCmds.color
         self.fallbacks['sidebar'] = PreambleCmds.sidebar
         self.out.append('\n\\DUsidebar{\n')
+        self.insert_DUclass_macros(node)
 
     def depart_sidebar(self, node):
         self.out.append('}\n')

Re: [Docutils-users] broken ..epigraph in XeTeX?

[Alan G. I. <ai...@am...>]

On 2/4/2017 11:51 AM, Matěj Cepl wrote:
>     \begin{quote}
>     \DUrole{epigraph}{
>     Co je nejvyšším cílem člověka?
>
>     Nejvyšším cílem člověka je oslavovat Boha a věčně se z Něj
>     radovat.
>     \nopagebreak
>
>     \raggedleft —Westminsterský katechismus, 1647
>     }
>     \end{quote}



Is this another abuse of the ``quote`` environment
to accomplish indentation?  If so, this again
compromises the ability to separately style
quotes and other content (in this case, epigraphs).

Note that the ``changepage`` package provides ``adjustwidth``.
E.g., one could define
\newenvironment{DUepigraph}%
{\begin{adjustwidth}{2cm}{}}%
{\end{adjustwidth}}

Other default formatting could be added as desired.
This approach would allow authors to readily modify
the ``epigraph`` environment (with ``renewenvironment``)
without interfering with other environments.

The ``quote`` environment is for (one paragraph) quotes.
It is not a general indentation facility.
https://en.wikibooks.org/wiki/LaTeX/Paragraph_Formatting#Quoting_text

Cheers,
Alan Isaac

[Docutils-users] broken ..epigraph in XeTeX?

[Matěj C. <mc...@ce...>]

So, I have a document which should start like this:


    Druhý život Petunie Dursleyové
    ##############################

    .. epigraph::

        Co je nejvyšším cílem člověka?

        Nejvyšším cílem člověka je oslavovat Boha a věčně se 
        z Něj radovat.

        -- Westminsterský katechismus, 1647

    Na cizinecké policii
    --------------------

    Hustě sněžilo, obloha byla zatažená a cítila se mizerně. 
    Její náladě ani nepřidalo to, že budova cizinecké policie 

This works perfectly with rst2html (or rst2html5 for that 
matter, which seems a way cooler ... thank you for that!), but 
it completely breaks rst2xetex. I get this LaTeX code for the 
epigraph:

    \begin{quote}
    \DUrole{epigraph}{
    Co je nejvyšším cílem člověka?

    Nejvyšším cílem člověka je oslavovat Boha a věčně se z Něj 
    radovat.
    \nopagebreak

    \raggedleft —Westminsterský katechismus, 1647
    }
    \end{quote}

And this error when run through xelatex:

    Runaway argument?
    { Co je nejvyšším cílem člověka? 
    ! Paragraph ended before \DUrole was complete.
    <to be read again> 
                       \par 
    l.71 
     
How can I have a paragraph break inside of ..epigraph?

Best,

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ce...
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Always make new mistakes
   -- Esther Dyson

[Docutils-users] weird footnotes in the generated LaTeX

[Matěj C. <mc...@ce...>]

Hi,

I have written a bit longer document using rST (all discussed 
files are in https://mcepl.fedorapeople.org/tmp/harry_potter/), 
and then convered it to LaTeX just with plain rst2xetex (using 
0.13.1). The resulting file is 
  https://mcepl.fedorapeople.org/tmp/harry_potter/harry-potter-odpoved-brachovi.pdf
and the problem I have it is that footnotes are quite often not 
on the page they referred to (see page 8 for an example). When 
I just hand-edited the LaTeX file and replaced all 
\DUfootnotetext & \DUfootnotemark constructs with plain 
\footnote and suddenly all footnotes are placed correctly (as 
expected from LaTeX; the file 
harry-potter-odpoved-brachovi-hand_edited.pdf).

Is there some configuration or something which would persuade 
docutils not to mess with footenotes and use plain \footnote{} 
in LaTeX?

Thank you,

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ce...
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
"Anything essential is invisible to the eyes", the little prince
repeated, in order to remember.
"It's the time you spent on your rose that makes your rose so
important."
"It's the time I spent on my rose ...," the little prince
repeated, in order to remember.
"People have forgotten this truth." the fox said. "But you
mustn't forget it.  You become responsible forever for what
you've tamed. You're responsible for your rose..."
"I'm responsible for my rose...," the little prince repeated, in
order to remember.
    -- Antoine de Saint-Exupéry: The Little Prince

Re: [Docutils-users] Naive question about the image directive

[Guenter M. <mi...@us...>]

On 2017-01-23, Chris Green wrote:
> On Mon, Jan 23, 2017 at 04:02:59PM +0000, Roberto Alsina wrote:
>>    If you are going to use relative URLs, they need to be relative to
>>    where the HTML page resides, not to where the rst text is.
>>    So, if your page ends at [1]http://foo.bar/boo/this.html with a
>>    relative URL to the image of "DSCF6584.JPG" then the image better be
>>    available at [2]http://foo/bar/boo/DSCF6584.JPG or it will not work.

> Unfortunately my HTML doesn't reside anywhere, it's generated by
> rst2html and eaten by a PHP script.  That's what I meant by it being
> generated 'dynamically'.

For the viewing browser, it should make no difference whether it is static
or dynamic: if you can view the generated HTML document under
http://example.org/this/is/a/dynamic/path/mydoc.html or
http://example.org/this/is/a/dynamic/path/mydoc.php,
a relative URL should be relative to http://example.org/this/is/a/dynamic/path/

but:

> I think basically there's no practical way to use relative URIs in my
> situation, they'll have to be absolute.

Indeed, absolute URIs seem to be the most practical solution for your problem.

Günter

Re: [Docutils-users] Naive question about the image directive

[Chris G. <cl...@is...>]

On Mon, Jan 23, 2017 at 04:02:59PM +0000, Roberto Alsina wrote:
>    If you are going to use relative URLs, they need to be relative to
>    where the HTML page resides, not to where the rst text is.
>    So, if your page ends at [1]http://foo.bar/boo/this.html with a
>    relative URL to the image of "DSCF6584.JPG" then the image better be
>    available at [2]http://foo/bar/boo/DSCF6584.JPG or it will not work.
> 
Unfortunately my HTML doesn't reside anywhere, it's generated by
rst2html and eaten by a PHP script.  That's what I meant by it being
generated 'dynamically'.

I think basically there's no practical way to use relative URIs in my
situation, they'll have to be absolute.


-- 
Chris Green

Re: [Docutils-users] Naive question about the image directive

[Roberto A. <ra...@kd...>]

If you are going to use relative URLs, they need to be relative to where
the HTML page resides, not to where the rst text is.

So, if your page ends at http://foo.bar/boo/this.html with a relative URL
to the image of "DSCF6584.JPG" then the image better be available at
http://foo/bar/boo/DSCF6584.JPG or it will not work.


On Mon, Jan 23, 2017 at 12:59 PM Chris Green <cl...@is...> wrote:

> > >
> > OK, thanks, I'll try a bit more.
> >
> OK, I've been trying some more!  :-)
>
> I can get the following to work:-
>
> .. image:: http://esprimo/mandyFlat/DSCF6584.JPG
>
>
> I can't get anything like this to work at all:-
>
> .. image:: DSCF6584.JPG
>
> (yes, I have copied the JPG file to the directory where the rst text is)
>
>
> The code it generates is:-
>
>     <img alt="DSCF6584.JPG" src="DSCF6584.JPG" />
>
> which is sort of alright except that, presumably, the web server
> (apache2) can't actually find the image with just that as the address.
> I guess the problem is down to the fact that the page is generated
> dynamically.
>
> --
> Chris Green
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Docutils-users mailing list
> Doc...@li...
> https://lists.sourceforge.net/lists/listinfo/docutils-users
>
> Please use "Reply All" to reply to the list.
>

Re: [Docutils-users] Naive question about the image directive

[Chris G. <cl...@is...>]

> > 
> OK, thanks, I'll try a bit more.
> 
OK, I've been trying some more!  :-)

I can get the following to work:-

.. image:: http://esprimo/mandyFlat/DSCF6584.JPG


I can't get anything like this to work at all:-

.. image:: DSCF6584.JPG                         

(yes, I have copied the JPG file to the directory where the rst text is)


The code it generates is:-

    <img alt="DSCF6584.JPG" src="DSCF6584.JPG" />

which is sort of alright except that, presumably, the web server
(apache2) can't actually find the image with just that as the address.
I guess the problem is down to the fact that the page is generated
dynamically.

-- 
Chris Green

Re: [Docutils-users] Naive question about the image directive

[Chris G. <cl...@is...>]

On Sun, Jan 22, 2017 at 09:46:13PM +0000, Guenter Milde wrote:
> On 2017-01-22, Chris Green wrote:
> > On Sun, Jan 22, 2017 at 09:58:55AM +0800, log4yes wrote:
> >> 在 2017年01月22日 02:52, Chris Green 写道:
> >> > This may be rather a silly question but at the moment I can't get the
> >> > image directive to do anything useful for me.
> >> >
> >> > The documentation shows the syntax as:-
> >> >
> >> >      .. image:: picture.png
> >> >
> >> > and says: "The URI for the image source file is specified in the
> >> > directive argument."
> >> >
> >> > So, does that picture.png have to be a full URI or what?  ... and
> >> > where will the picture.png file be exactly?
> 
> There has to be a file at the location pointed to by the URI.
> If the URI is picture.png, this means a file picture.png in the same
> direcory as the generated document.
> 
> > So what appears above as "picture.png" should actually be:-
> 
> >     http://server.mylan/pictures/picture.png
> 
> This would work for any document that can access this URI (provided it
> points to a valid image file).
> 
> > I'm using rst2html.
> 
> >> 2. Is there some error/warning?
> 
> > Not that I can see.  It's being run from PHP with stderr being
> > redirected to a file, that file is zero length (but does exist) so I
> > don't think there are any errors being reported.
> 
> When generating HTML and not giving options that require a look at the image
> (scaling, ...), the URI is not checked during the process.
> 
> Günter
> 
OK, thanks, I'll try a bit more.

-- 
Chris Green

Re: [Docutils-users] Naive question about the image directive

[Guenter M. <mi...@us...>]

On 2017-01-22, Chris Green wrote:
> On Sun, Jan 22, 2017 at 09:58:55AM +0800, log4yes wrote:
>> 在 2017年01月22日 02:52, Chris Green 写道:
>> > This may be rather a silly question but at the moment I can't get the
>> > image directive to do anything useful for me.
>> >
>> > The documentation shows the syntax as:-
>> >
>> >      .. image:: picture.png
>> >
>> > and says: "The URI for the image source file is specified in the
>> > directive argument."
>> >
>> > So, does that picture.png have to be a full URI or what?  ... and
>> > where will the picture.png file be exactly?

There has to be a file at the location pointed to by the URI.
If the URI is picture.png, this means a file picture.png in the same
direcory as the generated document.

> So what appears above as "picture.png" should actually be:-

>     http://server.mylan/pictures/picture.png

This would work for any document that can access this URI (provided it
points to a valid image file).

> I'm using rst2html.

>> 2. Is there some error/warning?

> Not that I can see.  It's being run from PHP with stderr being
> redirected to a file, that file is zero length (but does exist) so I
> don't think there are any errors being reported.

When generating HTML and not giving options that require a look at the image
(scaling, ...), the URI is not checked during the process.

Günter

Re: [Docutils-users] Naive question about the image directive

[Chris G. <cl...@is...>]

On Sun, Jan 22, 2017 at 09:58:55AM +0800, log4yes wrote:
> 在 2017年01月22日 02:52, Chris Green 写道:
> > This may be rather a silly question but at the moment I can't get the
> > image directive to do anything useful for me.
> >
> > The documentation shows the syntax as:-
> >
> >      .. image:: picture.png
> >
> > and says: "The URI for the image source file is specified in the
> > directive argument."
> >
> > So, does that picture.png have to be a full URI or what?  ... and
> > where will the picture.png file be exactly?
> >
> > All I can do at the moment is get to see the text "picture.png".
> >
> You can use relative path from your source file to the image, or full 
> uri(url). Make sure the path is correct.
> 
So what appears above as "picture.png" should actually be:-

    http://server.mylan/pictures/picture.png

(fictional address but that's the idea)

...or for a relative address:-

    ../../pictures/picture.png

(or something like that, does it need anything more?)


> Some more info will help:
> 1. How do you generate the output? e.g. rst2html, online editor, github 
> or blog using rst?

I'm using rst2html.


> 2. Is there some error/warning?
> 
Not that I can see.  It's being run from PHP with stderr being
redirected to a file, that file is zero length (but does exist) so I
don't think there are any errors being reported.


Thank you.

-- 
Chris Green

Re: [Docutils-users] Naive question about the image directive

[log4yes <lo...@gm...>]

You can use relative path from your source file to the image, or full 
uri(url). Make sure the path is correct.

Some more info will help:
1. How do you generate the output? e.g. rst2html, online editor, github 
or blog using rst?
2. Is there some error/warning?

在 2017年01月22日 02:52, Chris Green 写道:
> This may be rather a silly question but at the moment I can't get the
> image directive to do anything useful for me.
>
> The documentation shows the syntax as:-
>
>      .. image:: picture.png
>
> and says: "The URI for the image source file is specified in the
> directive argument."
>
> So, does that picture.png have to be a full URI or what?  ... and
> where will the picture.png file be exactly?
>
> All I can do at the moment is get to see the text "picture.png".
>

[Docutils-users] Naive question about the image directive

[Chris G. <cl...@is...>]

This may be rather a silly question but at the moment I can't get the
image directive to do anything useful for me.

The documentation shows the syntax as:-

    .. image:: picture.png

and says: "The URI for the image source file is specified in the
directive argument."

So, does that picture.png have to be a full URI or what?  ... and
where will the picture.png file be exactly?

All I can do at the moment is get to see the text "picture.png".

-- 
Chris Green

Re: [Docutils-users] [Docutils-develop] Version V1.5.1 of `rst.el`

[Stefan M. <st...@me...>]

Hi again!

5 days ago Stefan Merten wrote:
> I just committed V1.5.1 of `rst.el` to the SVN repository:

One bug escaped my tests :-( .

I just committed V1.5.2 of `rst.el` to the SVN repository:

	https://sourceforge.net/p/docutils/code/HEAD/tree/trunk/docutils/tools/editors/emacs/rst.el

The bug broke fontification of comments which continued on the same
line::

	.. This comment was no longer fontified

It's fixed (and a test is added).


						Grüße

						Stefan

Re: [Docutils-users] Migration docutils 0.12 to 0.13

[Guenter M. <mi...@us...>]

Dear David,

>> Is the patch still "on the table"?

> Yes, but I'm looking at making more extensive changes first. The patch
> that implemented the changes to support
> settings.character_level_inline_markup really made a mess of things:

...

> I'll work on all these and propose another patch.

thank you

Günter

Re: [Docutils-users] Migration docutils 0.12 to 0.13

[jean B. F. <web...@jb...>]

On 04/01/2017 06:23, David Goodger wrote:
> On Tue, Jan 3, 2017 at 4:07 AM, Jean Baptiste Favre
> <web...@jb...> wrote:
>> I finally get the build working with method level monkey patch as well
>> as your own patch Inliner8009.patch.
>>
>> But, since a successful build requires docutils to be updated, I'll
>> suggest to trafficserver devs to change the way it works and use the
>> classic docutils role way, which will be more stable.
> 
> Please give us a link to that discussion. I'd like to see how the decision goes.
> 
> Thanks,
> 
> David Goodger
> <http://python.net/~goodger>
> 

Discusion started in december here:
https://mail-archives.apache.org/mod_mbox/trafficserver-dev/201612.mbox/%3c6...@jb...%3e

And continued in January here:
https://mail-archives.apache.org/mod_mbox/trafficserver-dev/201701.mbox/thread

Bug report is here:
https://issues.apache.org/jira/browse/TS-5107

And Github PR here:
https://github.com/apache/trafficserver/pull/1296

Regards,
Jean Baptiste

Re: [Docutils-users] Migration docutils 0.12 to 0.13

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

On Tue, Jan 3, 2017 at 4:07 AM, Jean Baptiste Favre
<web...@jb...> wrote:
> I finally get the build working with method level monkey patch as well
> as your own patch Inliner8009.patch.
>
> But, since a successful build requires docutils to be updated, I'll
> suggest to trafficserver devs to change the way it works and use the
> classic docutils role way, which will be more stable.

Please give us a link to that discussion. I'd like to see how the decision goes.

Thanks,

David Goodger
<http://python.net/~goodger>

Re: [Docutils-users] Migration docutils 0.12 to 0.13

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

On Tue, Jan 3, 2017 at 3:13 AM, Guenter Milde <mi...@us...> wrote:
> Dear David,
>
> On 2017-01-02, David Goodger wrote:
>
>> Patch attached.
>
>>> You didn't do anything wrong that I can see. There was an internal
>>> change to Docutils in revision 7942 that refactored some code, and a
>>> side effect was to remove some attributes from the Inliner class (they
>>> became locals instead). Your code depends on these class attributes.
>
>>> Try applying the attached patch and let us know how it works. The
>>> missing class attributes will be present as instance attributes, which
>>> should be close enough.
>
>>> Günter, I think the attached patch should also be rolled into a 0.13.2
>>> bugfix release.
>
> Is the patch still "on the table"?

Yes, but I'm looking at making more extensive changes first. The patch
that implemented the changes to support
settings.character_level_inline_markup really made a mess of things:

1. Inliner.__init__ is currently a no-op (code: just "pass"). That
smells bad. Why even have the method if it does nothing? Prior to the
patch (in, say, r7640), it initialized self.implicit_dispatch. It
can't do that completely now, but it can initialize an empty
self.implicit_dispatch with a docstring.

2. My coding style is to initialize all instance attributes in the
__init__ method of a class, for easy reference, and include an
attribute docstring for documentation. The Inliner class now breaks
this style. I'd like to fix this.

3. The Inliner.init_customizations method grew from 6 physical lines
of code to almost 140 lines. This was because all of the formerly
statically defined class attributes were brought in, to be defined
dynamically depending on settings.character_level_inline_markup. I
plan to refactor this huge method into a small init_customizations and
shunt all the definitions into another method.

4. That ``args.update(vars(Inliner))`` line is fragile, and should be replaced.

I'll work on all these and propose another patch.

> Also with this patch, the attributes `start_string_prefix`,
> `end_string_suffix`, and `parts` are only available after calling
> ``inliner.init_customizations(document.settings)``.

This may change back to the prior status.

> Is there a use-case for this scenario we want to support?
> If not, we could define them as internal auxiliary variables after
> the API change that came with implementation of [ 103 ].

I want to restore the attributes (formerly class attributes, maybe now
they have to be instance attributes, although maybe not) that were
part of the de-facto API prior to [103]. We've seen one example of
client code that depended on these, and there may be others.

> That said, I am not against the patch. If including, I just propose a small
> correction:

Incorporated into my working copy.

David Goodger
<http://python.net/~goodger>

[Docutils-users] Version V1.5.1 of `rst.el`

[Stefan M. <st...@me...>]

Hi!

I just committed V1.5.1 of `rst.el` to the SVN repository:

  https://sourceforge.net/p/docutils/code/HEAD/tree/trunk/docutils/tools/editors/emacs/rst.el


This release contains mainly lots and lots of refactorings and only a
few user visible changes. This is the log message:

  Lots of refactorings and a few minor improvements.

  User visible improvements and changes:
  * Improve and debug `rst-forward-section` and `rst-backward-section`.
  * Auto-enumeration may be used with all styles for list insertion.
  * Improve and debug `rst-toc-insert`.
  * Adapt change in Emacs to use customization group `text` instead of `wp`.
  * Bind `n` and `p` in `rst-toc-mode`.
  * `z` in `toc-mode` returns to the previous window configuration.
  * Require Emacs version >= 24.1.

  Lots of refactorings including:
  * Silence byte compiler.
  * Use lexical binding.
  * Use `cl-lib`.
  * Add tests and raise test coverage.

I'm running lots of unit tests so I don't think anything is broken.
Nonetheless this may be the case. Don't hesitate to give me feedback
in this case.

I'm still refactoring `rst.el` but I'm nearly through with it. When
this is complete I'm going to implement new features and improve
existing ones.


						Grüße

						Stefan

Re: [Docutils-users] Migration docutils 0.12 to 0.13

[Jean B. F. <web...@jb...>]

Hello David,

On 03/01/2017 01:15, David Goodger wrote:
> On Mon, Jan 2, 2017 at 5:03 PM, Jean Baptiste Favre
> <web...@jb...> wrote:
>> Still have the same error.
>> The full traceback is attached, sorry to have forgotten it before.
>>
>> My subclass is as follow:
>>
>> from docutils import nodes
>> from docutils.parsers.rst import states
>> from docutils.utils import unescape
>>
>> # Customize parser.inliner in the only way that Sphinx supports.
>> # docutils.parsers.rst.Parser takes an instance of states.Inliner or a
>> # subclass but Sphinx initializes it from
>> # SphinxStandaloneReader.set_parser('restructuredtext') which is called
>> # from Publisher.set_components() and initializes the parser without
>> # arguments.
>>
>> BaseInliner = states.Inliner
>> class Inliner(BaseInliner):
>>
>>   def init_customizations(self, settings):
>>     BaseInliner.init_customizations(self, settings)
>>
>>     issue_pattern = re.compile(u'''
>>       {start_string_prefix}
>>       TS-\d+
>>       {end_string_suffix}'''.format(
>>         start_string_prefix=self.start_string_prefix,
>>         end_string_suffix=self.end_string_suffix),
>>       re.VERBOSE | re.UNICODE)
>>
>>     self.implicit_dispatch.append((issue_pattern, self.issue_reference))
>>
>>   def issue_reference(self, match, lineno):
>>     text = match.group(0)
>>
>>     rawsource = unescape(text, True)
>>     text = unescape(text, False)
>>
>>     refuri = 'https://issues.apache.org/jira/browse/' + text
>>
>>     return [nodes.reference(rawsource, text, refuri=refuri)]
>>
>> states.Inliner = Inliner
> 
> That last line is the culprit. You're monkey-patching Docutils. Don't
> do that. If something in Docutils breaks as a result, you can't
> reasonably complain. If it worked before, it was just accidental.

To make everything clear, I'm *not* the original author of this code,
but I completely agree with you :)

I'm "just" trying to fix trafficserver build against docutils 0.13.1 so
that trafficserver package isn't removed from Debian archive (stable
freeze is coming).
Right now, I only have 2 week left to make the build works in Debian.

> I distilled the issue down, see the attached x.py & y.py. Put them on
> your PYTHONPATH so y.py can import x.py. Run y.py. Note the output.
> Now edit y.py and uncomment the commented line (the monkey patch). Now
> run y.py again, and note the difference in the output. The monkey
> patch messes up the namespace hierarchy, so x.A.run doesn't have
> access to x.attr_x anymore.
> 
> Wasn't there another version of this code that worked in a different way?

I tried many things which never worked.

I finally get the build working with method level monkey patch as well
as your own patch Inliner8009.patch.

But, since a successful build requires docutils to be updated, I'll
suggest to trafficserver devs to change the way it works and use the
classic docutils role way, which will be more stable.

> Maybe you can monkey patch at the method level instead of the class
> level. I.e. inject your methods into the existing Docutils Inliner
> class, instead of replacing the class with your subclass. See z.py.
> Caveat: monkey patching is dangerous. Even if this works now, I can't
> guarantee that it will always work.
> You're trying to do this through Sphinx, which isn't configurable, as
> the comment in https://github.com/apache/trafficserver/blob/master/doc/conf.py
> describes:
> 
> # Customize parser.inliner in the only way that Sphinx supports.
> # docutils.parsers.rst.Parser takes an instance of states.Inliner or a
> # subclass but Sphinx initializes it from
> # SphinxStandaloneReader.set_parser('restructuredtext') which is called
> # from Publisher.set_components() and initializes the parser without
> # arguments.
> 
> Perhaps you should complain to Sphinx, and ask them to enable
> configurability. If your code was using Docutils directly this
> wouldn't be an issue (or would be less of an issue).

Which shouldn't be needed if trafficserver switch to classic docutils roles.

Thanks for your help and patience, I've learned a lot !

Cheers,
Jean Baptiste Favre

Re: [Docutils-users] Migration docutils 0.12 to 0.13

[Guenter M. <mi...@us...>]

Dear David,

On 2017-01-02, David Goodger wrote:

> Patch attached.

>> You didn't do anything wrong that I can see. There was an internal
>> change to Docutils in revision 7942 that refactored some code, and a
>> side effect was to remove some attributes from the Inliner class (they
>> became locals instead). Your code depends on these class attributes.

>> Try applying the attached patch and let us know how it works. The
>> missing class attributes will be present as instance attributes, which
>> should be close enough.

>> Günter, I think the attached patch should also be rolled into a 0.13.2
>> bugfix release.

Is the patch still "on the table"?

Also with this patch, the attributes `start_string_prefix`,
`end_string_suffix`, and `parts` are only available after calling
``inliner.init_customizations(document.settings)``. 

Is there a use-case for this scenario we want to support?
If not, we could define them as internal auxiliary variables after
the API change that came with implementation of [ 103 ].

That said, I am not against the patch. If including, I just propose a small
correction:


> Index: docutils/parsers/rst/states.py
>===================================================================
> --- docutils/parsers/rst/states.py	(revision 8008)
> +++ docutils/parsers/rst/states.py	(working copy)
> @@ -479,11 +479,13 @@
>                                   (punctuation_chars.closing_delimiters,
>                                    punctuation_chars.delimiters,
>                                    punctuation_chars.closers))
> +        self.start_string_prefix = start_string_prefix
> +        self.end_string_suffix = end_string_suffix

>          args = locals().copy()
>          args.update(vars(self.__class__))

> -        parts = ('initial_inline', start_string_prefix, '',
> +        parts = ('initial_inline', self.start_string_prefix, '',

No need to call the instance variable here, as we set it just some lines
above (overwriting an eventually existing instance).

>             [('start', '', self.non_whitespace_after, # simple start-strings
>               [r'\*\*',                # strong
>                r'\*(?!\*)',            # emphasis but not strong
> @@ -509,6 +511,7 @@
>               )
>              ]
>             )
> +        self.parts = parts

>          self.patterns = Struct(
>            initial=build_regexp(parts),


Thanks,

Günter

Re: [Docutils-users] Migration docutils 0.12 to 0.13

[Guenter M. <mi...@us...>]

On 2017-01-02, David Goodger wrote:
> On Sun, Jan 1, 2017 at 1:59 PM, Guenter Milde <mi...@us...> wrote:
>> On 2016-12-31, Jean Baptiste Favre wrote:
>>> Hello,
>>> I'm facing an issue with Trafficserver documentation [1] which doesn't
>>> build with docutils 0.13.1

>>> Error comes from a custom Inliner class which is defined in doc/conf.py
>>> of Trafficserver project(starting line 163).
...
>>> This custom Inliner used to work with docutils 0.12. It fails on 0.13.1
>>> with following error:

>>>   Exception occurred:
>>>     File "conf.py", line 185, in __init__
>>>       start_string_prefix=self.start_string_prefix,
>>>   AttributeError: Inliner instance has no attribute 'start_string_prefix'

>>> Since docutils 0.13, start_string_prefix isn't statically defined. We
>>> have to call init_customiations for that.

>> Yes, this changed with the implementation of the long expected feature

>>   - Apply [ 103 ] Recognize inline markups without word boundaries.

>> and the new configuration setting "character_level_inline_markup".

> This is another example of an API change coming back to bite us.

...

> Or we could fix our mistake. I think that's better.

I am not sure whether it was a mistake in this case:

The API change was discussed and the verdict was to use a switch to
solve the long-standing issue that makes reST difficult to use in
languages that don't use spaces as word delimiters.

__ https://sourceforge.net/p/docutils/patches/103/#f2f3

As a result, the `commit from 25 May 2016`__ 
implemented the `patch proposed by atsuo ishimoto`__ 

__ http://repo.or.cz/docutils.git/commitdiff/6839405e24a9a68e7cfd71643610d17115e6be2c
__ https://sourceforge.net/p/docutils/patches/_discuss/thread/e5337656/46b3/attachment/inline.patch.2

There is no easy way to implement 103 (new setting to allow character
level inline markup) without a change in the Inliner class. The
Inline.patterns becomes dependent on document settings.

Even if we define a static Inline.patterns default, using this default in
a 3rd party custom class inheriting from Inline may clash with the later
customization.

I see the following options:

a) revert the application of [ 103 ], reopening the
   "long-standing issue that makes reST difficult to use in languages
   that don't use spaces as word delimiters".
   
b) add documentation of this API change to the release notes in 0.13.2
   and help the OP to resolve the issue.

Günter

Re: [Docutils-users] Migration docutils 0.12 to 0.13

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

On Mon, Jan 2, 2017 at 5:03 PM, Jean Baptiste Favre
<web...@jb...> wrote:
> Still have the same error.
> The full traceback is attached, sorry to have forgotten it before.
>
> My subclass is as follow:
>
> from docutils import nodes
> from docutils.parsers.rst import states
> from docutils.utils import unescape
>
> # Customize parser.inliner in the only way that Sphinx supports.
> # docutils.parsers.rst.Parser takes an instance of states.Inliner or a
> # subclass but Sphinx initializes it from
> # SphinxStandaloneReader.set_parser('restructuredtext') which is called
> # from Publisher.set_components() and initializes the parser without
> # arguments.
>
> BaseInliner = states.Inliner
> class Inliner(BaseInliner):
>
>   def init_customizations(self, settings):
>     BaseInliner.init_customizations(self, settings)
>
>     issue_pattern = re.compile(u'''
>       {start_string_prefix}
>       TS-\d+
>       {end_string_suffix}'''.format(
>         start_string_prefix=self.start_string_prefix,
>         end_string_suffix=self.end_string_suffix),
>       re.VERBOSE | re.UNICODE)
>
>     self.implicit_dispatch.append((issue_pattern, self.issue_reference))
>
>   def issue_reference(self, match, lineno):
>     text = match.group(0)
>
>     rawsource = unescape(text, True)
>     text = unescape(text, False)
>
>     refuri = 'https://issues.apache.org/jira/browse/' + text
>
>     return [nodes.reference(rawsource, text, refuri=refuri)]
>
> states.Inliner = Inliner

That last line is the culprit. You're monkey-patching Docutils. Don't
do that. If something in Docutils breaks as a result, you can't
reasonably complain. If it worked before, it was just accidental.

I distilled the issue down, see the attached x.py & y.py. Put them on
your PYTHONPATH so y.py can import x.py. Run y.py. Note the output.
Now edit y.py and uncomment the commented line (the monkey patch). Now
run y.py again, and note the difference in the output. The monkey
patch messes up the namespace hierarchy, so x.A.run doesn't have
access to x.attr_x anymore.

Wasn't there another version of this code that worked in a different way?

Maybe you can monkey patch at the method level instead of the class
level. I.e. inject your methods into the existing Docutils Inliner
class, instead of replacing the class with your subclass. See z.py.
Caveat: monkey patching is dangerous. Even if this works now, I can't
guarantee that it will always work.

You're trying to do this through Sphinx, which isn't configurable, as
the comment in https://github.com/apache/trafficserver/blob/master/doc/conf.py
describes:

# Customize parser.inliner in the only way that Sphinx supports.
# docutils.parsers.rst.Parser takes an instance of states.Inliner or a
# subclass but Sphinx initializes it from
# SphinxStandaloneReader.set_parser('restructuredtext') which is called
# from Publisher.set_components() and initializes the parser without
# arguments.

Perhaps you should complain to Sphinx, and ask them to enable
configurability. If your code was using Docutils directly this
wouldn't be an issue (or would be less of an issue).

David Goodger
<http://python.net/~goodger>


> On 02/01/2017 22:53, David Goodger wrote:
>> On Mon, Jan 2, 2017 at 3:26 PM, Jean Baptiste Favre
>> <web...@jb...> wrote:
>>> Hello David,
>>>
>>> Thanks for your answer.
>>> Unfortunatly, the patch doesn't help.
>>>
>>> I still have a "KeyError: 'non_unescaped_whitespace_escape_before'" in
>>> docutils/parsers/rst/states.py at line 533.
>>
>> In future, please send a full traceback. We need to know the context
>> (what called what).
>>
>>> I guess it's the same kind of problem and I should redefine all local
>>> attributes (from lines 655 to 687) as class attributes as you did in the
>>> patch.
>>
>> I think I see what the problem is now. docutils/parsers/rst/states.py,
>> Inliner.init_customizations contains the following line::
>>
>>     args.update(vars(self.__class__))
>>
>> The "vars" function gets the __dict__ from the object's class. But
>> you're using a subclass, so vars returns the __dict__ of the subclass,
>> without the the superclass's attributes, which is what is needed. It's
>> a bit of metaprogramming gone wrong. It's not safe for subclassing,
>> which is a bug. It's already a bit of a kludgey shortcut. We could
>> replace it with::
>>
>>     args.update(vars(Inliner))
>>
>> That's a bit smelly, but I see it's done elsewhere in the code. Try
>> making that change (patch attached).
>>
>> We may have to explicitly refer to all the class attributes. I'll think on it.
>>
>> David Goodger
>>
>>> I'll test it asap and report,
>>> Cheers,
>>> Jean Baptiste
>>>
>>>

Re: [Docutils-users] Migration docutils 0.12 to 0.13

[Jean B. F. <web...@jb...>]

Still have the same error.
The full traceback is attached, sorry to have forgotten it before.

My subclass is as follow:

from docutils import nodes
from docutils.parsers.rst import states
from docutils.utils import unescape

# Customize parser.inliner in the only way that Sphinx supports.
# docutils.parsers.rst.Parser takes an instance of states.Inliner or a
# subclass but Sphinx initializes it from
# SphinxStandaloneReader.set_parser('restructuredtext') which is called
# from Publisher.set_components() and initializes the parser without
# arguments.

BaseInliner = states.Inliner
class Inliner(BaseInliner):

  def init_customizations(self, settings):
    BaseInliner.init_customizations(self, settings)

    issue_pattern = re.compile(u'''
      {start_string_prefix}
      TS-\d+
      {end_string_suffix}'''.format(
        start_string_prefix=self.start_string_prefix,
        end_string_suffix=self.end_string_suffix),
      re.VERBOSE | re.UNICODE)

    self.implicit_dispatch.append((issue_pattern, self.issue_reference))

  def issue_reference(self, match, lineno):
    text = match.group(0)

    rawsource = unescape(text, True)
    text = unescape(text, False)

    refuri = 'https://issues.apache.org/jira/browse/' + text

    return [nodes.reference(rawsource, text, refuri=refuri)]

states.Inliner = Inliner


Thanks,
Jean Baptiste

On 02/01/2017 22:53, David Goodger wrote:
> On Mon, Jan 2, 2017 at 3:26 PM, Jean Baptiste Favre
> <web...@jb...> wrote:
>> Hello David,
>>
>> Thanks for your answer.
>> Unfortunatly, the patch doesn't help.
>>
>> I still have a "KeyError: 'non_unescaped_whitespace_escape_before'" in
>> docutils/parsers/rst/states.py at line 533.
> 
> In future, please send a full traceback. We need to know the context
> (what called what).
> 
>> I guess it's the same kind of problem and I should redefine all local
>> attributes (from lines 655 to 687) as class attributes as you did in the
>> patch.
> 
> I think I see what the problem is now. docutils/parsers/rst/states.py,
> Inliner.init_customizations contains the following line::
> 
>     args.update(vars(self.__class__))
> 
> The "vars" function gets the __dict__ from the object's class. But
> you're using a subclass, so vars returns the __dict__ of the subclass,
> without the the superclass's attributes, which is what is needed. It's
> a bit of metaprogramming gone wrong. It's not safe for subclassing,
> which is a bug. It's already a bit of a kludgey shortcut. We could
> replace it with::
> 
>     args.update(vars(Inliner))
> 
> That's a bit smelly, but I see it's done elsewhere in the code. Try
> making that change (patch attached).
> 
> We may have to explicitly refer to all the class attributes. I'll think on it.
> 
> David Goodger
> 
>> I'll test it asap and report,
>> Cheers,
>> Jean Baptiste
>>
>>
>> On 02/01/2017 21:24, David Goodger wrote:
>>> On Sun, Jan 1, 2017 at 4:17 PM, Jean Baptiste Favre
>>> <web...@jb...> wrote:
>>>> Hello,
>>>> I tried another workaround.
>>>> Instead of using a custom class, I overrided init_cutomizations method
>>>> using:
>>>>
>>>>   class Inliner(BaseInliner):
>>>>     def __init(self):
>>>>       BaseInliner.__init__(self)
>>>>
>>>>     def init_customizations(self, settings):
>>>>       BaseInliner.init_customizations(self, settings)
>>>>
>>>>       issue_pattern = re.compile(u'''
>>>>         {start_string_prefix}
>>>>         TS-\d+
>>>>         {end_string_suffix}'''.format(
>>>>           start_string_prefix=self.start_string_prefix,
>>>>           end_string_suffix=self.end_string_suffix),
>>>>         re.VERBOSE | re.UNICODE)
>>>>
>>>>       self.implicit_dispatch.append((issue_pattern, self.issue_reference))
>>>>
>>>> I don't call explicitly init_customizations, but it's called: during
>>>> run, I still get the error:
>>>>
>>>>   Exception occurred:
>>>>     File
>>>> "/usr/lib/python2.7/dist-packages/docutils/parsers/rst/states.py", line
>>>> 530, in init_customizations
>>>>         """ % args, re.VERBOSE | re.UNICODE),
>>>>   KeyError: 'non_unescaped_whitespace_escape_before'
>>>>   The full traceback has been saved in /tmp/sphinx-err-wLtHoF.log, if
>>>> you want to report the issue to the developers.
>>>>   Please also report this if it was a user error, so that a better error
>>>> message can be provided next time.
>>>>   A bug report can be filed in the tracker at
>>>> <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
>>>>   make[6]: *** [man] Error 1
>>>>
>>>> What did I do wrong ?
>>>
>>> You didn't do anything wrong that I can see. There was an internal
>>> change to Docutils in revision 7942 that refactored some code, and a
>>> side effect was to remove some attributes from the Inliner class (they
>>> became locals instead). Your code depends on these class attributes.
>>>
>>> Try applying the attached patch and let us know how it works. The
>>> missing class attributes will be present as instance attributes, which
>>> should be close enough.
>>>
>>> Günter, I think the attached patch should also be rolled into a 0.13.2
>>> bugfix release.
>>>
>>> David Goodger
>>> <http://python.net/~goodger>
>>>
>>>
>>>> On 01/01/2017 20:59, Guenter Milde wrote:
>>>>> On 2016-12-31, Jean Baptiste Favre wrote:
>>>>>> Hello,
>>>>>> I'm facing an issue with Trafficserver documentation [1] which doesn't
>>>>>> build with docutils 0.13.1
>>>>>
>>>>>> Error comes from a custom Inliner class which is defined in doc/conf.py
>>>>>> of Trafficserver project(starting line 163).
>>>>>> This allow to transform text like "(TS-XXXX)" in a link to
>>>>>> trafficserver's Jira
>>>>>
>>>>>> This custom Inliner used to work with docutils 0.12. It fails on 0.13.1
>>>>>> with following error:
>>>>>
>>>>>>   Exception occurred:
>>>>>>     File "conf.py", line 185, in __init__
>>>>>>       start_string_prefix=self.start_string_prefix,
>>>>>>   AttributeError: Inliner instance has no attribute 'start_string_prefix'
>>>>>
>>>>>> Since docutils 0.13, start_string_prefix isn't statically defined. We
>>>>>> have to call init_customiations for that.
>>>>>
>>>>> Yes, this changed with the implementation of the long expected feature
>>>>>
>>>>>   - Apply [ 103 ] Recognize inline markups without word boundaries.
>>>>>
>>>>> and the new configuration setting "character_level_inline_markup".
>>>>>
>>>>>
>>>>>> First problem: one  must pass settings param when calling
>>>>>> init_customizations, but I can't find any format or structure for it.
>>>>>
>>>>>> Second problem: I tried a workaround, creating a InlinerSettings class
>>>>>> with minimal properties so that init_customizations could pass:
>>>>>
>>>>>>   class InlinerSettings:
>>>>>>     character_level_inline_markup=None
>>>>>>     pep_references=None
>>>>>>     rfc_references=None
>>>>>
>>>>>> But, then, I faced another error:
>>>>>
>>>>> ...
>>>>>
>>>>> "settings" is a an object returned from the option parser (optparse module).
>>>>>
>>>>> There are others facing similar problems, e.g. Python distutils.
>>>>> There, I learned the trick is to use
>>>>>
>>>>>   settings = frontend.OptionParser(components=(Parser,)).get_default_values()
>>>>>
>>>>>   -- https://hg.python.org/cpython/rev/db09d760b965
>>>>>
>>>>>
>>>>>> Third problem: since the above tries didn't worked, I'd a look on custom
>>>>>> directives and roles.
>>>>>> But, it does not seems to be allowed to define a role with a custom regex.
>>>>>> This would means I have to rewrite all "(TS-XXXX)" expression into ":TS:
>>>>>> XXXX".
>>>>>
>>>>> This is the "minimal-invasive" approach, it would be work now but might save
>>>>> issues later, as it depends less on Docutils internals.
>>>>>
>>>>>> Is there any way to achieve the migration in a compatible way with
>>>>>> docutils 0.12 *and* without rewriting the docuemntation ?
>>>>>
>>>>> If the above example does not lead to a solution, you could also consider to
>>>>> copy the definition of start_string_prefix ...
>>>>> from states.py (importing utils.punctuation_chars first)
>>>>>
>>>>> Günter
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Docutils-users mailing list
>> Doc...@li...
>> https://lists.sourceforge.net/lists/listinfo/docutils-users
>>
>> Please use "Reply All" to reply to the list.
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most 
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>
>>
>> _______________________________________________
>> Docutils-users mailing list
>> Doc...@li...
>> https://lists.sourceforge.net/lists/listinfo/docutils-users
>>
>> Please use "Reply All" to reply to the list.