docutils-develop — For developer discussions of the implementation.

Re: [Docutils-develop] [PATCH 0/9] Allow literal tabs in reStructuredText

[engelbert g. <eng...@gm...>]

Hello Jarret,

thinking about tabs

* python discourages usage hardtabs and space mixing, because becomes
painful (IMHO)
* python philosophy : explicit is better then implicit ... would an option
:hard-tabs: keep
  be more in line ?

cheers


On Sun, 29 Oct 2023 at 08:11, Jarret "Jax" Renker via Docutils-develop <
doc...@li...> wrote:

> Dear docutils developers
>
> I'm sending you a draft on how to handle literal tab characters inside
> reStructuredText documents.
>
> The Problem
> ===========
>
> Maybe we start with two examples.  From here on I'll denote the tab
> character
> with its escape sequence ``\t`` (in case it gets replaced by spaces).
>
> 1. tabs in Makefile listings/literal blocks
> -------------------------------------------
>
> Currently it is impossible for the *output* of a literal block to contain
> tabs.
> This breaks some listings, e.g. Makefile:
>
> >This is a Makefile::
> >
> >   all:
> >   \techo Hello
>
> This gets rendered as something like
>
> >This is a Makefile:
> ><pre>
> >all:
> >     echo Hello
> ></pre>
>
> Which is not a valid Makefile as the rules require a tab and not 5 spaces.
>
> This behaviour is also contrary to my expectation that a literal block
> leaves
> its content untouched.
>
> 2. CSV with tabs
> ----------------
>
> A common delimiter for a CSV-table (or should I say a CTV-table?) is the
> tab
> character.  Currently, the tab character is only supported for included CSV
> tables but not for inline ones.  The following does not work:
>
> >.. csv-table:: good delimiter
> >   :delim: tab
> >
> >   some\tcsv\tdata
>
> The problem is that all tab characters get replaced *prior* to parsing,
> namely
> in string2lines().
>
> An attempt for a solution
> =========================
>
> In an attempt to fix this, I toyed around with not replacing tab characters
> before parsing but handling them during parsing.  The parts concerned with
> indention parsing are the methods trim_left() and get_indented() of
> StringList.
> Adjusting them lets things "just work(tm)".  This is a draft, so some
> details
> and corner cases must still be sorted out.
>
> The above mentioned functions need the `tab_width` (currently at the
> default
> value of 8). Since I have not such a deep inside in the architecture of the
> parser, what would be the best way to pass that information to their
> consumer?
>
> Obviously we should somehow use the docutils.conf option tab_width.
>
> Here is some rambling of what I (don't) know:
>
> *  The StringList methods are called by their StateMachineWS counterparts,
>    which also does not have access to that information.  However, we could
>    make it a property of StateMachineWS.
>
> *  StateMachineWS subclasses RSTStateMachine and NestedStateMachine do have
>    access to document and hence to the tab_width setting.
>
> *  We could also put the information into the state.  In case we ever want
>    to change the tab_width during parsing, e.g. inside a directive this
>    might be the better place?
>
>    However, I don't know how longlived/isolated these states are, changing
>    the tab_width inside a directive should neither effect the next
> directive
>    nor the rest of the document.
>
> Regards
> Jax
>
>
> _______________________________________________
> Docutils-develop mailing list
> Doc...@li...
> https://lists.sourceforge.net/lists/listinfo/docutils-develop
>
> Please use "Reply All" to reply to the list.
>

[Docutils-develop] [docutils:bugs] #475 man output produces broken tables

[engelbert g. <gr...@us...>]

- **labels**:  --> manpage writer
- **assigned_to**: engelbert gruber



---

**[bugs:#475] man output produces broken tables**

**Status:** open
**Labels:** manpage writer 
**Created:** Mon Sep 25, 2023 03:57 PM UTC by Kovid Goyal
**Last Updated:** Tue Oct 10, 2023 12:37 PM UTC
**Owner:** engelbert gruber


The docutils.writers.manpage.Table class produces suboptimal table markup that causes display issues depending on terminal window size. This is because of the way the external table borders are specified.
Currently the class uses | and _ to generate lines for the external borders. The correct way to do it is to use the "box" option. If you do that, groff will take care of generating the external border itself and this one renders properly in terminals. I have monkeypatched the Table class in my project to do this, here is the code: https://github.com/kovidgoyal/kitty/blob/master/docs/conf.py#L550




---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:feature-requests] #99 Support scaleable images in html (along with other SVG features)

[Günter M. <mi...@us...>]

> Scaleable images formats (i.e. SVG) should be scaleable in those output formats (i.e. HTML) where the page size is not fixed (i.e. a web browser).

This is already possible, the :width: parameter allows a percentage value that is interpreted relative to the line length.

For use cases where this is still too limiting, support for the CSS3 lenght units vh, vw, vmin, and vmax  [feature-request:57] may be a better approach.


---

**[feature-requests:#99] Support scaleable images in html (along with other SVG features)**

**Status:** open
**Group:** Default
**Created:** Sat Oct 28, 2023 10:02 PM UTC by Karl O. Pinc
**Last Updated:** Sun Oct 29, 2023 11:53 AM UTC
**Owner:** nobody


Scaleable images formats (i.e. SVG) should be scaleable in those output formats (i.e. HTML) where the page size is not fixed (i.e. a web browser).

A major benefit of SVG is that it scales.  Make the window bigger or smaller and the image adjusts accordingly.  RST does not seem to support this.  (See link at bottom for a work-around using "raw".  But the work-around works only for images, not figures.)

It would be nice if the image and figure directives allowed the "scale:" option to take the values "width" and "height".  These would allow the image to scale to the width or height of the browser's window while maintaining the image's aspect ratio.  These 2 new values can be ignored when generating output with fixed page sizes.

Alternately, introduce a new option.   (resize?)  Doing so would side-step the issue of how to specify option values that vary depending on the chosen output format.

It seems  that the right way to implement this is by generating an inline HTML svg tag that contains an SVG image tag referencing the svg file which is to be part of the document.  CSS can then control how the scaling is done.

A related matter is the ability to have interactive SVG documents, which respond to keyboard, pointer, and document events.  Apparently, these features are not realizable when embedding SVG with a HTML image tag.  This is another argument for an inline HTML svg tag.

Finally, SVG supports embedded hyperlinks.  I'm unclear on whether this is "interactive" or not but wouldn't want to forgo the ability to click on a portion of a diagram and be taken to the relevant section in the documentation.  (It seems hyperlinks are an SVG 2.0 feature.  But the feature does seem to be supported for SVG v1.1 generaed by Inkscape and displayed in a browser.)

See also the following Sphinx bug:
https://github.com/sphinx-doc/sphinx/issues/2240




---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:feature-requests] #99 Support scaleable images in html (along with other SVG features)

[engelbert g. <gr...@us...>]

i am curious, how would the reStructured text look for the examples ?


---

**[feature-requests:#99] Support scaleable images in html (along with other SVG features)**

**Status:** open
**Group:** Default
**Created:** Sat Oct 28, 2023 10:02 PM UTC by Karl O. Pinc
**Last Updated:** Sat Oct 28, 2023 10:02 PM UTC
**Owner:** nobody


Scaleable images formats (i.e. SVG) should be scaleable in those output formats (i.e. HTML) where the page size is not fixed (i.e. a web browser).

A major benefit of SVG is that it scales.  Make the window bigger or smaller and the image adjusts accordingly.  RST does not seem to support this.  (See link at bottom for a work-around using "raw".  But the work-around works only for images, not figures.)

It would be nice if the image and figure directives allowed the "scale:" option to take the values "width" and "height".  These would allow the image to scale to the width or height of the browser's window while maintaining the image's aspect ratio.  These 2 new values can be ignored when generating output with fixed page sizes.

Alternately, introduce a new option.   (resize?)  Doing so would side-step the issue of how to specify option values that vary depending on the chosen output format.

It seems  that the right way to implement this is by generating an inline HTML svg tag that contains an SVG image tag referencing the svg file which is to be part of the document.  CSS can then control how the scaling is done.

A related matter is the ability to have interactive SVG documents, which respond to keyboard, pointer, and document events.  Apparently, these features are not realizable when embedding SVG with a HTML image tag.  This is another argument for an inline HTML svg tag.

Finally, SVG supports embedded hyperlinks.  I'm unclear on whether this is "interactive" or not but wouldn't want to forgo the ability to click on a portion of a diagram and be taken to the relevant section in the documentation.  (It seems hyperlinks are an SVG 2.0 feature.  But the feature does seem to be supported for SVG v1.1 generaed by Inkscape and displayed in a browser.)

See also the following Sphinx bug:
https://github.com/sphinx-doc/sphinx/issues/2240




---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:feature-requests] #98 Warn on title underline too long

[Günter M. <mi...@us...>]

Thank you for the suggestion. It would need a lot of thinking about detail to get it right:

What should be done with headers like

     ***************
          this
     ***************
(no warning, warning if left an right overhang differs, ...)?

How about styles where a title underline should always be 75 characters wide?

Is it really worth defining a new setting for "don't warn about too long underlines".
Would this open the way to a setting for disabling every single warning type?

Should we opt for a generic setting "--disable-warning-of-type" and define names for the warning types/classes that can be used in this setting? ...

I would class a too long underline rather as a stylistic issue, that similar to line-length,
TAB use etc. should be enforced by external means, not the Docutils core.




---

**[feature-requests:#98] Warn on title underline too long**

**Status:** open
**Group:** Default
**Created:** Sat Oct 28, 2023 10:14 AM UTC by xypron
**Last Updated:** Sat Oct 28, 2023 10:14 AM UTC
**Owner:** nobody


If title underlines are too short, docutils creates a warning:

docutils/parsers/rst/states.py:2750:
        msg = self.reporter.warning('Title underline too short.', 

Many documentation projects want the underline to match the title. It would be great if we could have a warning for titles that are too long too.  Maybe some switch would be needed to disable the warning.



---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [PATCH 9/9] CSV Table: Add test with tab as delimiter

[Jarret \Jax\ R. <jar...@pr...>]

---
 .../test_rst/test_directives/test_tables.py   | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/docutils/test/test_parsers/test_rst/test_directives/test_tables.py b/docutils/test/test_parsers/test_rst/test_directives/test_tables.py
index 8a97ee812..b408c3fdb 100755
--- a/docutils/test/test_parsers/test_rst/test_directives/test_tables.py
+++ b/docutils/test/test_parsers/test_rst/test_directives/test_tables.py
@@ -993,6 +993,11 @@ def test_parser(self):
    :delim: space
 
    some csv data
+
+.. csv-table:: good delimiter
+   :delim: tab
+
+   some	csv	data
 """,
 """\
 <document source="test data">
@@ -1068,6 +1073,24 @@ def test_parser(self):
                     <entry>
                         <paragraph>
                             data
+    <table>
+        <title>
+            good delimiter
+        <tgroup cols="3">
+            <colspec colwidth="33">
+            <colspec colwidth="33">
+            <colspec colwidth="33">
+            <tbody>
+                <row>
+                    <entry>
+                        <paragraph>
+                            some
+                    <entry>
+                        <paragraph>
+                            csv
+                    <entry>
+                        <paragraph>
+                            data
 """],
 ["""\
 .. csv-table:: bad delimiter

[Docutils-develop] [PATCH 8/9] StringList: Add test for get_indented() with tabs

[Jarret \Jax\ R. <jar...@pr...>]

---
 docutils/test/test_viewlist.py | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/docutils/test/test_viewlist.py b/docutils/test/test_viewlist.py
index faa0bd098..fa8ff02e2 100755
--- a/docutils/test/test_viewlist.py
+++ b/docutils/test/test_viewlist.py
@@ -198,6 +198,11 @@ class StringList(unittest.TestCase):
       literal
            block"""
 
+    indented_string_with_tab = """\
+        Here is some
+\tindented text.
+"""
+
     def setUp(self):
         self.a_list = self.text.splitlines(True)
         self.a = statemachine.StringList(self.a_list, 'a')
@@ -214,6 +219,10 @@ def test_get_indented(self):
             statemachine.string2lines(self.indented_string))
         self.assertEqual(block.get_indented(),
                          ([s[6:] for s in block], 6, 1))
+        block = statemachine.StringList(
+            statemachine.string2lines(self.indented_string_with_tab))
+        self.assertEqual(block.get_indented(),
+                         ([s.expandtabs()[8:] for s in block], 8, 1))
 
 
 if __name__ == '__main__':

[Docutils-develop] [PATCH 7/9] StringList.get_indented(): Support indention by tabs

[Jarret \Jax\ R. <jar...@pr...>]

Support calculating indention with tabs, e.g. 1 tab = 8 spaces.
---
 docutils/docutils/statemachine.py | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/docutils/docutils/statemachine.py b/docutils/docutils/statemachine.py
index c1f07b57e..681563d19 100644
--- a/docutils/docutils/statemachine.py
+++ b/docutils/docutils/statemachine.py
@@ -1358,7 +1358,7 @@ def get_text_block(self, start, flush_left=False):
         return self[start:end]
 
     def get_indented(self, start=0, until_blank=False, strip_indent=True,
-                     block_indent=None, first_indent=None):
+                     block_indent=None, first_indent=None, tab_width=8):
         """
         Extract and return a StringList of indented lines of text.
 
@@ -1367,12 +1367,17 @@ def get_indented(self, start=0, until_blank=False, strip_indent=True,
         `strip_indent` is false), and return them. All lines up to but not
         including the first unindented line will be returned.
 
+        The indention is calculated for the logical text position.  That is
+        a tab character is `tab_width` spaces wide instead of 1.
+        See `logical_rslice()` for details.
+
         :Parameters:
           - `start`: The index of the first line to examine.
           - `until_blank`: Stop collecting at the first blank line if true.
           - `strip_indent`: Strip common leading indent if true (default).
           - `block_indent`: The indent of the entire block, if known.
           - `first_indent`: The indent of the first line, if known.
+          - `tab_width`: tab stop positions "1 tab = `tab_width` spaces"
 
         :Return:
           - a StringList of indented lines with minimum indent removed;
@@ -1388,7 +1393,7 @@ def get_indented(self, start=0, until_blank=False, strip_indent=True,
         last = len(self.data)
         while end < last:
             line = self.data[end]
-            if line and (line[0] != ' '
+            if line and ((line[0] not in ' \t')
                          or (block_indent is not None
                              and line[:block_indent].strip())):
                 # Line not indented or insufficiently indented.
@@ -1402,7 +1407,8 @@ def get_indented(self, start=0, until_blank=False, strip_indent=True,
                     blank_finish = 1
                     break
             elif block_indent is None:
-                line_indent = len(line) - len(stripped)
+                indent_chars = line[:-len(stripped)]
+                line_indent = len(indent_chars.expandtabs(tab_width))
                 if indent is None:
                     indent = line_indent
                 else:
@@ -1412,9 +1418,9 @@ def get_indented(self, start=0, until_blank=False, strip_indent=True,
             blank_finish = 1            # block ends at end of lines
         block = self[start:end]
         if first_indent is not None and block:
-            block.data[0] = block.data[0][first_indent:]
+            block.data[0] = logical_rslice(block.data[0], first_indent, tab_width)
         if indent and strip_indent:
-            block.trim_left(indent, start=(first_indent is not None))
+            block.trim_left(indent, start=(first_indent is not None), tab_width=tab_width)
         return block, indent or 0, blank_finish
 
     def get_2D_block(self, top, left, bottom, right, strip_indent=True):

[Docutils-develop] [PATCH 6/9] StringList.get_text_block(): Support indention by tabs

[Jarret \Jax\ R. <jar...@pr...>]

---
 docutils/docutils/statemachine.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docutils/docutils/statemachine.py b/docutils/docutils/statemachine.py
index 4b482c57e..c1f07b57e 100644
--- a/docutils/docutils/statemachine.py
+++ b/docutils/docutils/statemachine.py
@@ -1350,7 +1350,7 @@ def get_text_block(self, start, flush_left=False):
             line = self.data[end]
             if not line.strip():
                 break
-            if flush_left and (line[0] == ' '):
+            if flush_left and (line[0] in ' \t'):
                 source, offset = self.info(end)
                 raise UnexpectedIndentationError(self[start:end], source,
                                                  offset + 1)

[Docutils-develop] [PATCH 5/9] StringList.trim_left() support logical tab width

[Jarret \Jax\ R. <jar...@pr...>]

Support logical width for tab characters in the trim_left() function.
---
 docutils/docutils/statemachine.py | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/docutils/docutils/statemachine.py b/docutils/docutils/statemachine.py
index 167cb7744..4b482c57e 100644
--- a/docutils/docutils/statemachine.py
+++ b/docutils/docutils/statemachine.py
@@ -1324,13 +1324,16 @@ class StringList(ViewList):
 
     """A `ViewList` with string-specific methods."""
 
-    def trim_left(self, length, start=0, end=sys.maxsize):
+    def trim_left(self, length, start=0, end=sys.maxsize, tab_width=8):
         """
-        Trim `length` characters off the beginning of each item, in-place,
-        from index `start` to `end`.  No whitespace-checking is done on the
-        trimmed text.  Does not affect slice parent.
+        Trim `length` logical characters off the beginning of each item,
+        in-place, from index `start` to `end`.  No whitespace-checking is done
+        on the trimmed text.  Does not affect slice parent.
+
+        A tab counts (depending on the column) for up to `tab_width` characters.
+        See `logical_rslice()` for details.
         """
-        self.data[start:end] = [line[length:]
+        self.data[start:end] = [logical_rslice(line, length, tab_width)
                                 for line in self.data[start:end]]
 
     def get_text_block(self, start, flush_left=False):

[Docutils-develop] [PATCH 4/9] Add logical_rslice() function

[Jarret \Jax\ R. <jar...@pr...>]

Add a function which works like ``string[start:]`` except that tabs are
not counted as a single character but as `tab_width` characters wide.
---
 docutils/docutils/statemachine.py  | 66 ++++++++++++++++++++++++++++++
 docutils/test/test_statemachine.py | 16 ++++++++
 2 files changed, 82 insertions(+)

diff --git a/docutils/docutils/statemachine.py b/docutils/docutils/statemachine.py
index 890572564..167cb7744 100644
--- a/docutils/docutils/statemachine.py
+++ b/docutils/docutils/statemachine.py
@@ -1496,6 +1496,72 @@ def string2lines(astring):
     return astring.splitlines()
 
 
+def logical_rslice(astring, logical_start, tab_width):
+    """
+    Removes characters from the beginning of `astring` such that the logical
+    width of the removed characters is `logical_start`.  If `astring` is
+    logically shorter than `logical_start`, then an empty string is returned.
+
+    For all except the tab character, the logical width is 1.  If `tab_width`
+    >= 0, then a tab character is considered to be up to `tab_width` spaces
+    wide depending on the current column in `astring` and the next tab
+    position.  A tab position is every tab_width columns.  For a description of
+    tab positions see str.expandtabs().
+
+    If `logical_start` is such that only parts of a single tab character should
+    be removed from `astring`.  Then the tab character is replaced by spaces
+    and only the necessary amount of spaces is stripped.  In other words, the
+    tab is "broken apart in the middle" and the left over parts are replaced
+    with spaces.
+
+    Note:
+
+    > logical_rslice(astring, logical_start, tab_width)
+
+    is almost equivalent to
+
+    > astring.expandtabs(tab_width)[logical_start:]
+
+    except that only tabs in the stripped prefix are expanded into spaces,
+    other tab characters are left untouched.
+
+    Examples:
+
+    >>> logical_rslice("foo", 2, 8)
+    "o"
+    >>> logical_rslice("  \tfoo", 2, 8)
+    "\tfoo"
+    >>> logical_rslice("\tfoo", 5, 8)
+    "   foo"
+    >>> logical_rslice("  \tfoo", 5, 8)
+    "   foo"
+
+    Parameters:
+
+    - `astring`: a string to strip from
+    - `logical_start`: a number of logical character width to strip
+    - `tab_width`: the tab width
+    """
+    logical_pos = 0
+    string_pos = 0 # physical position in string
+    space_prefix = ''
+    try:
+        while logical_pos < logical_start:
+            ch = astring[string_pos]
+            string_pos += 1
+            if ch == '\t':
+                if tab_width > 0:
+                    logical_pos += tab_width - (logical_pos % tab_width)
+                else:
+                    pass
+            else:
+                logical_pos += 1
+        return (' ' * (logical_pos - logical_start)) + astring[string_pos:]
+    except IndexError:
+        # `astring` was logically shorter than `logical_start`
+        return ''
+
+
 def _exception_data():
     """
     Return exception information:
diff --git a/docutils/test/test_statemachine.py b/docutils/test/test_statemachine.py
index 8332a5a61..19f2bd874 100755
--- a/docutils/test/test_statemachine.py
+++ b/docutils/test/test_statemachine.py
@@ -290,6 +290,22 @@ def test_string2lines(self):
         self.assertEqual(statemachine.string2lines(self.s2l_string),
                          self.s2l_expected)
 
+    logical_rslice_test_data = [
+        # (input, logical_start, tab_width, expected)
+        ("foo\tfoo", 3,  8, "\tfoo"),
+        ("   \tfoo", 3,  8, "\tfoo"),
+        ("\tfoo",    3,  8, "     foo"),
+        ("   \tfoo", 8,  8, "foo"),
+        ("   \tfoo", 9,  8, "oo"),
+        ("   \tfoo", 9, 10, " foo"),
+        ("\tfoo",    5,  8, "   foo"),
+        ("\tfoo",    5,  1, ""),
+    ]
+
+    def test_logical_rslice(self):
+        for (i,s,t,e) in self.logical_rslice_test_data:
+            self.assertEqual(statemachine.logical_rslice(i,s,t), e)
+
 
 if __name__ == '__main__':
     unittest.main()

[Docutils-develop] [PATCH 3/9] Add tests for handling tabs inside literal block ``::``

[Jarret \Jax\ R. <jar...@pr...>]

---
 .../test_rst/test_literal_blocks.py           | 59 +++++++++++++++++++
 1 file changed, 59 insertions(+)

diff --git a/docutils/test/test_parsers/test_rst/test_literal_blocks.py b/docutils/test/test_parsers/test_rst/test_literal_blocks.py
index 95dd6a79f..123c35b11 100755
--- a/docutils/test/test_parsers/test_rst/test_literal_blocks.py
+++ b/docutils/test/test_parsers/test_rst/test_literal_blocks.py
@@ -384,6 +384,65 @@ def test_parser(self):
 """],
 ]
 
+totest['literal_blocks_with_tabs'] = [
+["""\
+A literal block with an indented tab::
+
+    A literal block.
+    \t<-- with a tab
+""",
+"""\
+<document source="test data">
+    <paragraph>
+        A literal block with an indented tab:
+    <literal_block xml:space="preserve">
+        A literal block.
+        \t<-- with a tab
+"""],
+["""\
+A literal block with a non-indented tab::
+
+    A literal block.
+\t<-- with a tab
+""",
+"""\
+<document source="test data">
+    <paragraph>
+        A literal block with a non-indented tab:
+    <literal_block xml:space="preserve">
+        A literal block.
+            <-- with a tab
+"""],
+["""\
+A literal block with an indented tab first::
+
+    \t<-- with a tab
+    A literal block.
+""",
+"""\
+<document source="test data">
+    <paragraph>
+        A literal block with an indented tab first:
+    <literal_block xml:space="preserve">
+        \t<-- with a tab
+        A literal block.
+"""],
+["""\
+A literal block with a non-indented tab first::
+
+\t<-- with a tab
+    A literal block.
+""",
+"""\
+<document source="test data">
+    <paragraph>
+        A literal block with a non-indented tab first:
+    <literal_block xml:space="preserve">
+            <-- with a tab
+        A literal block.
+"""],
+]
+
 
 if __name__ == '__main__':
     unittest.main()

[Docutils-develop] [PATCH 2/9] Update test of string2lines() to match new behaviour

[Jarret \Jax\ R. <jar...@pr...>]

---
 docutils/test/test_statemachine.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docutils/test/test_statemachine.py b/docutils/test/test_statemachine.py
index fa62720aa..8332a5a61 100755
--- a/docutils/test/test_statemachine.py
+++ b/docutils/test/test_statemachine.py
@@ -283,8 +283,8 @@ def test_make_transitions(self):
 class MiscTests(unittest.TestCase):
 
     s2l_string = "hello\tthere\thow are\tyou?\n\tI'm fine\tthanks.\n"
-    s2l_expected = ['hello   there   how are you?',
-                    "        I'm fine        thanks."]
+    s2l_expected = ['hello\tthere\thow are\tyou?',
+                    "\tI'm fine\tthanks."]
 
     def test_string2lines(self):
         self.assertEqual(statemachine.string2lines(self.s2l_string),

[Docutils-develop] [PATCH 1/9] string2lines(): Do not convert some whitespace into space

[Jarret \Jax\ R. <jar...@pr...>]

To allow tabs and other whitespace to be part of the output, we must not
remove it prior to parsing.  The handling of whitespace is done during
parsing.

We remove the stripping of whitespace "to the right" as some listing,
e.g. for the Programming Language Whitespace might relay on that.

Also note that there is more whitespace in Unicode than just Space
(`` ``), Tab (``\t``), Vertical Tab (``\v``), and Form Feed (``\f``).
---
 docutils/docutils/parsers/rst/__init__.py       |  4 +---
 .../docutils/parsers/rst/directives/misc.py     |  3 +--
 docutils/docutils/statemachine.py               | 17 +++--------------
 3 files changed, 5 insertions(+), 19 deletions(-)

diff --git a/docutils/docutils/parsers/rst/__init__.py b/docutils/docutils/parsers/rst/__init__.py
index 1eadbfe33..b8f45a45f 100644
--- a/docutils/docutils/parsers/rst/__init__.py
+++ b/docutils/docutils/parsers/rst/__init__.py
@@ -171,9 +171,7 @@ def parse(self, inputstring, document):
               state_classes=self.state_classes,
               initial_state=self.initial_state,
               debug=document.reporter.debug_flag)
-        inputlines = docutils.statemachine.string2lines(
-              inputstring, tab_width=document.settings.tab_width,
-              convert_whitespace=True)
+        inputlines = docutils.statemachine.string2lines(inputstring)
         for i, line in enumerate(inputlines):
             if len(line) > self.document.settings.line_length_limit:
                 error = self.document.reporter.error(
diff --git a/docutils/docutils/parsers/rst/directives/misc.py b/docutils/docutils/parsers/rst/directives/misc.py
index 85032d8e2..4b8043a5b 100644
--- a/docutils/docutils/parsers/rst/directives/misc.py
+++ b/docutils/docutils/parsers/rst/directives/misc.py
@@ -117,8 +117,7 @@ def run(self):
                                   'directive:\nText not found.' % self.name)
             rawtext = rawtext[:before_index]
 
-        include_lines = statemachine.string2lines(rawtext, tab_width,
-                                                  convert_whitespace=True)
+        include_lines = statemachine.string2lines(rawtext)
         for i, line in enumerate(include_lines):
             if len(line) > settings.line_length_limit:
                 raise self.warning('"%s": line %d exceeds the'
diff --git a/docutils/docutils/statemachine.py b/docutils/docutils/statemachine.py
index e3ea892bc..890572564 100644
--- a/docutils/docutils/statemachine.py
+++ b/docutils/docutils/statemachine.py
@@ -1485,26 +1485,15 @@ class StateCorrection(Exception):
     """
 
 
-def string2lines(astring, tab_width=8, convert_whitespace=False,
-                 whitespace=re.compile('[\v\f]')):
+def string2lines(astring):
     """
-    Return a list of one-line strings with tabs expanded, no newlines, and
-    trailing whitespace stripped.
-
-    Each tab is expanded with between 1 and `tab_width` spaces, so that the
-    next character's index becomes a multiple of `tab_width` (8 by default).
+    Return a list of one-line strings.
 
     Parameters:
 
     - `astring`: a multi-line string.
-    - `tab_width`: the number of columns between tab stops.
-    - `convert_whitespace`: convert form feeds and vertical tabs to spaces?
-    - `whitespace`: pattern object with the to-be-converted
-      whitespace characters (default [\\v\\f]).
     """
-    if convert_whitespace:
-        astring = whitespace.sub(' ', astring)
-    return [s.expandtabs(tab_width).rstrip() for s in astring.splitlines()]
+    return astring.splitlines()
 
 
 def _exception_data():

[Docutils-develop] [PATCH 0/9] Allow literal tabs in reStructuredText

[Jarret \Jax\ R. <jar...@pr...>]

Dear docutils developers

I'm sending you a draft on how to handle literal tab characters inside
reStructuredText documents.

The Problem
===========

Maybe we start with two examples.  From here on I'll denote the tab character
with its escape sequence ``\t`` (in case it gets replaced by spaces).

1. tabs in Makefile listings/literal blocks
-------------------------------------------

Currently it is impossible for the *output* of a literal block to contain tabs.
This breaks some listings, e.g. Makefile:

>This is a Makefile::
>
>   all:
>   \techo Hello

This gets rendered as something like

>This is a Makefile:
><pre>
>all:
>     echo Hello
></pre>

Which is not a valid Makefile as the rules require a tab and not 5 spaces.

This behaviour is also contrary to my expectation that a literal block leaves
its content untouched.

2. CSV with tabs
----------------

A common delimiter for a CSV-table (or should I say a CTV-table?) is the tab
character.  Currently, the tab character is only supported for included CSV
tables but not for inline ones.  The following does not work:

>.. csv-table:: good delimiter
>   :delim: tab
>
>   some\tcsv\tdata

The problem is that all tab characters get replaced *prior* to parsing, namely
in string2lines().

An attempt for a solution
=========================

In an attempt to fix this, I toyed around with not replacing tab characters
before parsing but handling them during parsing.  The parts concerned with
indention parsing are the methods trim_left() and get_indented() of StringList.
Adjusting them lets things "just work(tm)".  This is a draft, so some details
and corner cases must still be sorted out.

The above mentioned functions need the `tab_width` (currently at the default
value of 8). Since I have not such a deep inside in the architecture of the
parser, what would be the best way to pass that information to their consumer?

Obviously we should somehow use the docutils.conf option tab_width.

Here is some rambling of what I (don't) know:

*  The StringList methods are called by their StateMachineWS counterparts,
   which also does not have access to that information.  However, we could
   make it a property of StateMachineWS.

*  StateMachineWS subclasses RSTStateMachine and NestedStateMachine do have
   access to document and hence to the tab_width setting.

*  We could also put the information into the state.  In case we ever want
   to change the tab_width during parsing, e.g. inside a directive this
   might be the better place?

   However, I don't know how longlived/isolated these states are, changing
   the tab_width inside a directive should neither effect the next directive
   nor the rest of the document.

Regards
Jax

[Docutils-develop] [docutils:feature-requests] #98 Warn on title underline too long

[xypron <xy...@us...>]

---

**[feature-requests:#98] Warn on title underline too long**

**Status:** open
**Group:** Default
**Created:** Sat Oct 28, 2023 10:14 AM UTC by xypron
**Last Updated:** Sat Oct 28, 2023 10:14 AM UTC
**Owner:** nobody


If title underlines are too short, docutils creates a warning:

docutils/parsers/rst/states.py:2750:
        msg = self.reporter.warning('Title underline too short.', 

Many documentation projects want the underline to match the title. It would be great if we could have a warning for titles that are too long too.  Maybe some switch would be needed to disable the warning.



---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:patches] #207 manpage writer: Fix typos in macro names in TODO.

[engelbert g. <gr...@us...>]

- **status**: open --> closed-accepted



---

**[patches:#207] manpage writer: Fix typos in macro names in TODO.**

**Status:** closed-accepted
**Group:** None
**Created:** Sat Oct 07, 2023 01:57 AM UTC by G. Branden Robinson
**Last Updated:** Sat Oct 07, 2023 01:57 AM UTC
**Owner:** nobody
**Attachments:**

- [docutils.diff](https://sourceforge.net/p/docutils/patches/207/attachment/docutils.diff) (842 Bytes; text/x-patch)


Here's a patch to fix some typos in the recent changes to the manpage-writer TODO file.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] docutils/docs/user/manpage.txt TODO items

[G. B. R. <g.b...@gm...>]

Hi folks,

In looking over the Python docutils repo I spotted this list of
questions/problems and thought I could help.

> TODO - Open issues
> ''''''''''''''''''
>
> How to escape double quotes in macro arguments ?

  Use the special character escape sequence ``\(dq``.
  groff_man_style(7) explains.

       \(dq   Basic Latin quotation mark (double quote).  Use in macro
              calls to prevent ‘"” from being interpreted as beginning a
              quoted argument, or simply for readability.

                     .TP
                     .BI "split \(dq" text \(dq

> How to typeset command/manpage names in text.

  There are conflicting traditions and conventions on these points.
  groff_man_style(7) has recommendations.

              Use bold for literal portions of syntax synopses, for
              command‐line options in running text, and for literals
              that are major topics of the subject under discussion; for
              example, this page uses bold for macro, string, and
              register names.  In an .EX/.EE example of interactive I/O
              (such as a shell session), set only user input in bold.

              Use italics for file and path names, for environment
              variables, for C data types, for enumeration or
              preprocessor constants in C, for variant (user‐
              replaceable) portions of syntax synopses, for the first
              occurrence (only) of a technical concept being introduced,
              for names of journals and of literary works longer than an
              article, and anywhere a parameter requiring replacement by
              the user is encountered.  An exception involves variant
              text in a context already typeset in italics, such as file
              or path names with replaceable components; in such cases,
              follow the convention of mathematical typography: set the
              file or path name in italics as usual but use roman for
              the variant part (see .IR and .RI below), and italics
              again in running roman text when referring to the variant
              material.

  Plan 9 from User Space troff and groff 1.23.0 support an ``MR`` macro
  for the specific purpose of setting man page cross references.  It is
  reasonable to assume that groff 1.23.0 has not propagated yet to every
  platform Python docutils would like to support yet.  You can wait
  until it has, or supply a fallback definition in the man(7) documents
  you generate.

``.\" Define fallback for groff 1.23's MR macro if the system lacks it.
  .nr df 0 \" do fallback?
  .if !\n(.f           .nr df 1 \" mandoc
  .if  \n(.g .if !d MR .nr df 1 \" older groff
  .if !\n(.g           .nr df 1 \" non-groff *roff
  .if \n(df \{\
  .de MR
  .ie \\n(.$=1 \
  .I \%\\$1
  .el \
  .IR \%\\$1 (\\$2)\\$3
  ..
  .\}
  .rr df``

> How to write long syntax lines.

  groff_man_style(7) explains.

       \newline
              Join the next input line to the current one.  Except for
              the update of the input line counter (used for diagnostic
              messages and related purposes), a series of lines ending
              in backslash‐newline appears to groff as a single input
              line.  Use this escape sequence to split excessively long
              input lines for document maintenance.

> Line ends around email or web addresses in texts.
> How to distinguish something is inline or not ?

  groff_man_style(7) explains.

       \c     End a text line without inserting space or attempting a
              break.  Normally, if filling is enabled, the end of a text
              line is treated like a space; an output line may be broken
              there (if not, an adjustable space is inserted); if
              filling is disabled, the line will be broken there, as in
              .EX/.EE examples.  The next line is interpreted as usual
              and can include a macro call (contrast with \newline).  \c
              is useful when three font styles are needed in a single
              word, as in a command synopsis.

                     .RB [ \-\-stylesheet=\c
                     .IR name ]

              It also helps when changing font styles in .EX/.EE
              examples, since they are not filled.

                     .EX
                     $ \c
                     .B groff \-T utf8 \-Z \c
                     .I file \c
                     .B | grotty \-i
                     .EE

  Here's an example using groff's ``MR`` and ``ME`` macros.

``Mail the maintainer (\c
  .MR ma...@ex...
  Arthur Pewtey
  .UE )
  to submit patches.``

> Images and equations are discouraged.

  Unfortunately, yes.

> Lists in admonitions are not intended.

  This one I can't answer; I'll have to read more about Python docutils
  to understand the semantics and scope of admonitions.

> Encoding declaration ``'\" t -*- coding: ISO-8859-1 -*-``
> in first line.

  I would put Emacs file-local variables at the *end* of a man(7)
  document, not the beginning, but I admit I don't know of a mandb(8) or
  makewhatis(8) program in deployment on systems that Python docutils
  cares about that actually screws this up.

  Also, the ``t`` part of that is a hint to man(1) that it should run
  the tbl(1) preprocessor.  If you don't generate a tbl(1) table, you
  don't need the ``t`` in your first line.

> BUT if UTF-8 is declared tables are no longer processed.

  That's very strange.  If you can still reproduce this I'd appreciate a
  bug report.

> Input and output encoding are problematic at least.

  They shouldn't be with use of man-db man(1).  If you use groff
  directly, two factors are important.

  1.  Pass groff the ``-k`` option to tell it to run preconv(1) to
      attempt detection and translation of the character encoding used
      by the document.

  2.  Make sure you use an output device appropriate to the terminal's
      encoding.  You can run nroff(1) instead of groff(1) directly to
      have the system try to figure it out, or you can explicitly
      specify a ``-T`` option (to either nroff or groff).  groff
      supports the following.

      ``-T ascii``
      ``-T cp1047``
      ``-T latin1``
      ``-T utf8``

Let me know if any of the above is unclear or if I can be of further
assistance.

Regards,
Branden

[Docutils-develop] [docutils:patches] #203 Catalan updates

[Günter M. <mi...@us...>]

Thanks for the patch, commited in { [r9457].



---

**[patches:#203] Catalan updates**

**Status:** open-accepted
**Group:** None
**Created:** Sun Jul 23, 2023 09:38 PM UTC by Antoni Bella Pérez
**Last Updated:** Sun Oct 01, 2023 10:10 AM UTC
**Owner:** nobody
**Attachments:**

- [docutils-catalan_update.patch](https://sourceforge.net/p/docutils/patches/203/attachment/docutils-catalan_update.patch) (4.4 kB; text/x-patch)


* Has been ordered to following the source better (in English)
* All right from original translator


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:patches] #203 Catalan updates

[Günter M. <mi...@us...>]

- **status**: open --> open-accepted
- **Comment**:

Thank you for the update.
The patch (with some cosmetic changes) is now in the repository [r9451].

If you can confirm, that all translations are correct for the Valencian variant of Catalan
as-is, we should add a comment like

    # These translations can be used without changes for 
    # Valencian variant of Catalan (use language tag "ca-valencia").
    # Checked by a native speaker of Valentian.
    
in the files
and eventually add ""Natural Language ::  Catalan (Valencian)" to the trove-classifiers in our metadata. (This would require to add this tag to the official Python trove classifiers (alongside Georgian, cf.  https://github.com/pypa/trove-classifiers/issues/151).



---

**[patches:#203] Catalan updates**

**Status:** open-accepted
**Group:** None
**Created:** Sun Jul 23, 2023 09:38 PM UTC by Antoni Bella Pérez
**Last Updated:** Tue Aug 08, 2023 02:33 PM UTC
**Owner:** nobody
**Attachments:**

- [docutils-catalan_update.patch](https://sourceforge.net/p/docutils/patches/203/attachment/docutils-catalan_update.patch) (4.4 kB; text/x-patch)


* Has been ordered to following the source better (in English)
* All right from original translator


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] r9448 "Updated build stystem to use Flit"

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

Dear Engelbert,

thanks for the commit.
I realised that the legacy file "setup.py" is still present.

Is this intentional? (I don't think it is a good idea to have two files
with metadata -- requires double effort for each change and the danger of
mismatches is large.)

Günter

[Docutils-develop] [docutils:patches] #186 Modernise packaging

[Günter M. <mi...@us...>]

The attached patches are an attempt to update Adams contribution to work with  [r9447].

Building with "flit 3.9.0" works. Resulting archives must still be tested for completeness, spurious files and correctness.


Attachments:

- [0001-Modernise-packaging.-Re-move-old-metadata-files.patch](https://sourceforge.net/p/docutils/patches/_discuss/thread/e3c9702768/db5a/attachment/0001-Modernise-packaging.-Re-move-old-metadata-files.patch) (1.6 kB; text/x-patch)
- [0002-Rewrite-metadata-in-TOML-format-for-use-with-flit.patch](https://sourceforge.net/p/docutils/patches/_discuss/thread/e3c9702768/db5a/attachment/0002-Rewrite-metadata-in-TOML-format-for-use-with-flit.patch) (7.4 kB; text/x-patch)


---

**[patches:#186] Modernise packaging**

**Status:** open
**Group:** None
**Created:** Fri Dec 31, 2021 03:16 AM UTC by Adam  Turner
**Last Updated:** Mon Jun 26, 2023 08:07 PM UTC
**Owner:** nobody
**Attachments:**

- [0001-Use-flit-and-pyproject.toml.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0001-Use-flit-and-pyproject.toml.patch) (12.2 kB; application/octet-stream)
- [0002-Use-entry-points.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0002-Use-entry-points.patch) (20.7 kB; application/octet-stream)
- [0003-update-docs-etc-after-packaging-changes.patch](https://sourceforge.net/p/docutils/patches/186/attachment/0003-update-docs-etc-after-packaging-changes.patch) (49.3 kB; application/octet-stream)


Hi,

I had a go at modernising the packaging stack. `setup.py` based invocations have been deprecated (https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html), and setuptools may remove them in the future. 

This takes the opportunity to move to a PEP 621 based declarative config, and also fixes a longstanding TODO item about providing script wappers for the frontend tools on windows, by migrating them to entry points.

I've updated install and development docs with the new guidance, and updated references to the frontend tools to remove `.py`, given they are now installed as proper scripts.

Hope this is appreciated -- happy to make revisions etc to help getting this merged.

A


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] #473 Pip installs an incompatible version (20.1) for Python 2

[engelbert g. <gr...@us...>]

the wheel of 0.20.1 is rejected and the tgz is used 
but setup.py in https://docutils.sourceforge.io/0.20.1/setup.py states 
~~~
'python_requires': '>=3.7',
~~~
and 

~~~
  'Programming Language :: Python :: 3',
    'Programming Language :: Python :: 3.7',
    'Programming Language :: Python :: 3.8',
    'Programming Language :: Python :: 3.9',
    'Programming Language :: Python :: 3.10',
    'Programming Language :: Python :: 3.11',
~~~
  
  but pip 8 knows about py3 
  
  possibly desperate last thing before giving up is use newest tgz



---

**[bugs:#473] Pip installs an incompatible version (20.1) for Python 2**

**Status:** open
**Created:** Thu Aug 31, 2023 10:29 AM UTC by Richard Fennessy
**Last Updated:** Thu Aug 31, 2023 10:29 AM UTC
**Owner:** nobody


Hi,

Recently, we've noticed that running the command `pip install docutils` on an old host with only Python 2 installed has begun to install an incompatible version, `20.1`. (First noticed when the incompatibility broke `awscli`).

The output of `pip install docutils -vvv` shows that previous versions are correctly rejected, but  `20.1` is accepted for some reason:

(truncated for clarity)
~~~
    Found link https://files.pythonhosted.org/packages/57/b1/b880503681ea1b64df05106fc7e3c4e3801736cf63deffc6fa7fc5404cf5/docutils-0.18.1.tar.gz#sha256=679987caf361a7539d76e584cbeddc311e3aee937877c87346f31debc63e9d06 (from https://pypi.org/simple/docutils/), version: 0.18.1
    Found link https://files.pythonhosted.org/packages/ac/f7/aec2c4e0acabe771b207ff2b480f2bc1adaef02771ff12f9561e66df33cf/docutils-0.19b1-py2.py3-none-any.whl#sha256=bf87502630148119873347981a8efc2438e6f254f995b7699501f0e4aa538915 (from https://pypi.org/simple/docutils/), version: 0.19b1
    Found link https://files.pythonhosted.org/packages/cf/65/85a3da30f9a256a29b9cf947d603848eb6a4339900df73fbd56551c8b844/docutils-0.19b1.tar.gz#sha256=79b3ab5228b154ecaf4cbf08a1d8c213e3a127826193bafb5a035d0a7a88af0c (from https://pypi.org/simple/docutils/), version: 0.19b1
    Skipping link https://files.pythonhosted.org/packages/93/69/e391bd51bc08ed9141ecd899a0ddb61ab6465309f1eb470905c0c8868081/docutils-0.19-py3-none-any.whl#sha256=5e1de4d849fee02c63b040a4a3fd567f4ab104defd8a5511fbbc24a8a017efbc (from https://pypi.org/simple/docutils/); it is not compatible with this Python
    Found link https://files.pythonhosted.org/packages/6b/5c/330ea8d383eb2ce973df34d1239b3b21e91cd8c865d21ff82902d952f91f/docutils-0.19.tar.gz#sha256=33995a6753c30b7f577febfc2c50411fec6aac7f7ffeb7c4cfe5991072dcf9e6 (from https://pypi.org/simple/docutils/), version: 0.19
    Skipping link https://files.pythonhosted.org/packages/73/f1/455c0f5f29e853956947745299e65c494fe7ed49bce41fd05a738d931da3/docutils-0.20rc1-py3-none-any.whl#sha256=f9cd313159e9611199127c59b63c4890e808cb8cb6c2fe5f9a271cfd6df32676 (from https://pypi.org/simple/docutils/); it is not compatible with this Python
    Found link https://files.pythonhosted.org/packages/1d/0e/f03180dcf1e0727083dc5a303f15cacaf7ae1686f0a4efc295f5ff938197/docutils-0.20rc1.tar.gz#sha256=1077d5e5a529972f340550a99f55c59420095e40eb0eef0824083557a6589e98 (from https://pypi.org/simple/docutils/), version: 0.20rc1
    Skipping link https://files.pythonhosted.org/packages/41/3b/11740ed0f36e408ff3d5bd259af0c3330d899c17562f9964b7fbc90756f9/docutils-0.20-py3-none-any.whl#sha256=a428f10de4de4774389734c986a01b4af2d802d26717108b0f1b9356862937c5 (from https://pypi.org/simple/docutils/); it is not compatible with this Python
    Found link https://files.pythonhosted.org/packages/e6/a9/8ddfaa7a9414e42520e0041d1354ebda699e4eb1b47e2f1b6d8bda66aba6/docutils-0.20.tar.gz#sha256=f75a5a52fbcacd81b47e42888ad2b380748aaccfb3f13af0fe69deb759f01eb6 (from https://pypi.org/simple/docutils/), version: 0.20
    Skipping link https://files.pythonhosted.org/packages/26/87/f238c0670b94533ac0353a4e2a1a771a0cc73277b88bff23d3ae35a256c1/docutils-0.20.1-py3-none-any.whl#sha256=96f387a2c5562db4476f09f13bbab2192e764cac08ebbf3a34a95d9b1e4a59d6 (from https://pypi.org/simple/docutils/); it is not compatible with this Python
    Found link https://files.pythonhosted.org/packages/1f/53/a5da4f2c5739cf66290fac1431ee52aff6851c7c8ffd8264f13affd7bcdd/docutils-0.20.1.tar.gz#sha256=f08a4e276c3a1583a86dce3e34aba3fe04d02bba2dd51ed16106244e8a923e3b (from https://pypi.org/simple/docutils/), version: 0.20.1
  Using version 0.20.1 (newest of versions: 0.3, 0.3.5, 0.3.7, 0.3.9, 0.4, 0.5, 0.6, 0.7, 0.8, 0.8.1, 0.9, 0.9.1, 0.10, 0.11, 0.12, 0.13.1, 0.14, 0.15, 0.15.post1, 0.15.1, 0.15.1.post1, 0.15.2, 0.16, 0.17, 0.17.1, 0.18, 0.18.1, 0.19, 0.20, 0.20.1)
  Looking up "https://files.pythonhosted.org/packages/1f/53/a5da4f2c5739cf66290fac1431ee52aff6851c7c8ffd8264f13affd7bcdd/docutils-0.20.1.tar.gz" in the cache
  Current age based on date: 759150
  Freshness lifetime from max-age: 365000000
  The response is "fresh", returning cached response
  365000000 > 759150
  Using cached https://files.pythonhosted.org/packages/1f/53/a5da4f2c5739cf66290fac1431ee52aff6851c7c8ffd8264f13affd7bcdd/docutils-0.20.1.tar.gz
  Downloading from URL https://files.pythonhosted.org/packages/1f/53/a5da4f2c5739cf66290fac1431ee52aff6851c7c8ffd8264f13affd7bcdd/docutils-0.20.1.tar.gz#sha256=f08a4e276c3a1583a86dce3e34aba3fe04d02bba2dd51ed16106244e8a923e3b (from https://pypi.org/simple/docutils/)
  Running setup.py (path:/tmp/pip-build-U_uehq/docutils/setup.py) egg_info for package docutils
    Running command python setup.py egg_info
    /usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'python_requires'
      warnings.warn(msg)
    running egg_info
    creating pip-egg-info/docutils.egg-info
    writing pip-egg-info/docutils.egg-info/PKG-INFO
    writing top-level names to pip-egg-info/docutils.egg-info/top_level.txt
    writing dependency_links to pip-egg-info/docutils.egg-info/dependency_links.txt
    writing entry points to pip-egg-info/docutils.egg-info/entry_points.txt
    writing manifest file 'pip-egg-info/docutils.egg-info/SOURCES.txt'
    warning: manifest_maker: standard file '-c' not found

    package init file 'docutils/parsers/rst/include/__init__.py' not found (or not a regular file)
    package init file 'docutils/writers/s5_html/themes/__init__.py' not found (or not a regular file)
    package init file 'docutils/writers/s5_html/themes/default/__init__.py' not found (or not a regular file)
    reading manifest file 'pip-egg-info/docutils.egg-info/SOURCES.txt'
    reading manifest template 'MANIFEST.in'
    warning: no previously-included files found matching 'test/alltests.out'
    warning: no previously-included files found matching 'test/record.txt'
    warning: no previously-included files matching '*.pyc' found anywhere in distribution
    warning: no previously-included files matching '*~' found anywhere in distribution
    warning: no previously-included files matching '__pycache__' found anywhere in distribution
    warning: no previously-included files matching '.DS_Store' found anywhere in distribution
    writing manifest file 'pip-egg-info/docutils.egg-info/SOURCES.txt'
  Source in /tmp/pip-build-U_uehq/docutils has version 0.20.1, which satisfies requirement docutils from https://files.pythonhosted.org/packages/1f/53/a5da4f2c5739cf66290fac1431ee52aff6851c7c8ffd8264f13affd7bcdd/docutils-0.20.1.tar.gz#sha256=f08a4e276c3a1583a86dce3e34aba3fe04d02bba2dd51ed16106244e8a923e3b
~~~

pip version 8.1.2
CentOS Linux 7 (Core)
Linux 3.10.0-1160.95.1.el7.x86_64


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:patches] #204 Add Georgian translation

[engelbert g. <gr...@us...>]

- **status**: open --> open-accepted



---

**[patches:#204] Add Georgian translation**

**Status:** open-accepted
**Group:** None
**Created:** Mon Jul 24, 2023 03:54 AM UTC by Temuri Doghonadze
**Last Updated:** Mon Jul 24, 2023 03:54 AM UTC
**Owner:** nobody
**Attachments:**

- [ka.patch](https://sourceforge.net/p/docutils/patches/204/attachment/ka.patch) (7.3 kB; application/octet-stream)


Initial upload of Georgian translation.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:feature-requests] #72 rst2man: Show reference targets

[engelbert g. <gr...@us...>]

- **status**: open --> open-fixed
- **Comment**:

using  .UR/.UE



---

**[feature-requests:#72] rst2man: Show reference targets**

**Status:** open-fixed
**Group:** Default
**Created:** Wed Aug 26, 2020 03:47 PM UTC by Petr Viktorin
**Last Updated:** Mon Aug 07, 2023 12:29 PM UTC
**Owner:** engelbert gruber


Currently, the manpage writer writes a reference like `ALT TEXT <URL>` as just `ALT TEXT`, with alternate font.
Would it be better to render it as, for example, `ALT TEXT [URL]`, so the information is not lost?


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.