docutils-develop — For developer discussions of the implementation.

[Docutils-develop] [docutils:bugs] #437 Text.rawsource incorrectly removed (or falsely advertised) in 0.18

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

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

Fixed in release 0.19 (2022-07-05).

The plan is now to 
 >Remove the "rawsource" argument from nodes.Text.__init__()
    (deprecated and ignored since Docutils 0.18) in Docutils 2.0.

Thank you for the report.



---

** [bugs:#437] Text.rawsource incorrectly removed (or falsely advertised) in 0.18**

**Status:** closed-fixed
**Created:** Mon Nov 29, 2021 05:37 PM UTC by Rodrigo Tobar
**Last Updated:** Fri Dec 03, 2021 09:18 AM UTC
**Owner:** nobody


The attribute `Text.rawsource` has been removed already in version 0.18, but the [release notes](https://docutils.sourceforge.io/RELEASE-NOTES.html) show this as a "future change". What is the correct stance?

This is currently affecting [pospell](https://github.com/AFPy/pospell/issues/30), which has pinned its dependency on docutils to `docutils>=0.11,<0.18`.


---

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:bugs] #443 html5 writer no longer honors "[html writers]" config section

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

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

Release 0.19 (2022-07-05) fixes the issue.
Thank you for the report.



---

** [bugs:#443] html5 writer no longer honors "[html writers]" config section**

**Status:** closed-fixed
**Labels:** HTML writer 
**Created:** Tue Jan 25, 2022 07:51 PM UTC by John Thorvald Wodder II
**Last Updated:** Wed Jan 26, 2022 09:34 AM UTC
**Owner:** nobody


Under both version 0.18 and version 0.18.1 of Docutils, `rst2html5.py` does not recognize configuration settings in an `[html writers]` section in `docutils.conf`.  This appears to be due to commit 8722, in which `_html_base.py` was edited to no longer include `"html writers"` in its `config_section_dependencies`, instead moving the value to `config_section`; while `html4css1/__init__.py` was updated in the same commit to include `"html writers"` in its `config_section_dependencies`, `html5_polyglot/__init__.py` did not get the same treatment.


---

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:bugs] #444 Table column width rounding can result in uneven column widths

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

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

The table collumn bug is fixed in Release 0.19 (2022-07-05).
Docutils 0.19 should also work nice with "recommonmark" and the development version of Sphinx.



---

** [bugs:#444] Table column width rounding can result in uneven column widths**

**Status:** closed-fixed
**Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich
**Last Updated:** Sun Feb 20, 2022 05:55 AM UTC
**Owner:** nobody


In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%).  The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer.


---

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:bugs] #445 docutils generates links to redirecting PEP URLs

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

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

Fixed in Docutils 0.19.
Thank you for the report.



---

** [bugs:#445] docutils generates links to redirecting PEP URLs**

**Status:** closed-fixed
**Created:** Fri Mar 11, 2022 09:16 AM UTC by Arek_Fu
**Last Updated:** Sun Mar 13, 2022 06:59 PM UTC
**Owner:** nobody


The official URL for PEPs seems to have recently changed to the format [https://peps.python.org/pep-0008/](https://peps.python.org/pep-0008/). The links generated by docutils have the form [https://www.python.org/dev/peps/pep-0008](https://www.python.org/dev/peps/pep-0008); this redirects to the official URL, but it raises warnings in Sphinx's linkcheck builder. I initially thought this was an issue with Sphinx and opened a bug report [there](https://github.com/sphinx-doc/sphinx/issues/10253), but I think the links are actually generated by docutils.

Expected behaviour: docutils should generate links to the new PEP URLs.


---

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:bugs] #447 docutils-cli.py not available when installing via pip

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

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

Fixed in Docutils 0.19.
https://docutils.sourceforge.io/docs/user/tools.html#generic-command-line-front-end
Thank you for reporting.



---

** [bugs:#447] docutils-cli.py not available when installing via pip**

**Status:** closed-fixed
**Created:** Thu Apr 21, 2022 07:19 PM UTC by Jesse Brennan
**Last Updated:** Mon May 30, 2022 04:57 PM UTC
**Owner:** nobody


This might not be an actual bug, but the behavior is surprising, and the documentation lead me to believe that docutils-cli.py should be available regardless of installation method.

I created a new virtual environment with Python 3.8.3. With the virtual environment active, I updated to the latest version of pip, then installed docutils.

I then tried to run docutils-cli.py but the command could not be found. Other tools were available, such as rst2html.py.


---

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:bugs] #448 `Element.index()` returns incorrect results for `Text` nodes

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

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

Fixed in Docutils 0.19.
Thank you for reporting.



---

** [bugs:#448] `Element.index()` returns incorrect results for `Text` nodes**

**Status:** closed-fixed
**Created:** Tue May 24, 2022 11:38 PM UTC by Adam  Turner
**Last Updated:** Fri Jun 10, 2022 11:12 AM UTC
**Owner:** nobody


This captures the bug behind `branches/index-bug`. I'm not sure the general case of `index` is worth fixing, as `Text` nodes are a special case, but it might have implications for `Node.findall`.


```python
>>> from docutils import nodes
>>> tree = nodes.Element()
>>> blah1 = nodes.Text("blah")
>>> blah2 = nodes.Text("blah")
>>> tree += [nodes.Text("node1"), blah1, blah2]
>>> print(tree.pformat())
<Element>
    node1
    blah
    blah

>>> tree[tree.index(blah2)] is blah2
False
>>> tree[tree.index(blah2)] is blah1
True
```

A


---

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:bugs] #450 0.18: New HTML markup for footnotes is difficult to stylise

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

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

Fixed in Docutils 0.19.
Thank you for reporting.



---

** [bugs:#450] 0.18: New HTML markup for footnotes is difficult to stylise**

**Status:** closed-fixed
**Created:** Sun Jun 05, 2022 08:28 PM UTC by Pradyun Gedam
**Last Updated:** Sun Jun 19, 2022 08:25 PM UTC
**Owner:** nobody


Docutils 0.18 changed the HTML markup for footnotes/citations generated for rst documents. This changed markup is significantly more difficult to stylise with CSS, in ways that was possible with Docutils 0.17. This has negatively affected HTML themes for Sphinx, since the Sphinx 5 release allows using docutils 0.18, which is preferentially installed by `pip`.

The reasons for this boils down to an inconsistent number of elements inside each `aside`.

1. It's not possible use CSS grid layouts sanely, with this setup.
2. Even if you added multiple rules based on number of elements in the section, it's not possible to know what the 2nd element might be -- which balloons the complexity+size of the stylesheet, if it tries to accomodate for this.

It is theoretically possible to stylise this but it would be on the order of 100s of lines of CSS to get this right, compared to ~20 with 0.17.

Would it be possible to change this markup, to wrap the label & backrefs in a `div` and to wrap the content paragraphs in a separate `div` as well? This would make it possible to stylise this content in ways that were feasible with 0.17, with significantly less complexity in the stylesheets.

---

Sources:

```
[some content that references these footnotes]

.. [1] A footnote contains body elements, consistently indented by at
   least 3 spaces.

   This is the footnote's second paragraph.

.. [#label] Footnotes may be numbered, either manually (as in [1]_) or
   automatically using a "#"-prefixed label.  This footnote has a
   label so it can be referred to from multiple places, both as a
   footnote reference ([#label]_) and as a hyperlink reference
   (label_).

```

0.17 output HTML:

```
<dl class="footnote brackets">
  <dt class="label" id="id6"><span class="brackets">1</span><span class="fn-backref">(<a href="#id1">1</a>,<a
        href="#id7">2</a>)</span></dt>
  <dd>
    <p>A footnote contains body elements, consistently indented by at
      least 3 spaces.</p>
    <p>This is the footnote’s second paragraph.</p>
  </dd>
  <dt class="label" id="label"><span class="brackets">2</span><span class="fn-backref">(<a href="#id3">1</a>,<a
        href="#id8">2</a>)</span></dt>
  <dd>
    <p>Footnotes may be numbered, either manually (as in <a class="footnote-reference brackets" href="#id6"
        id="id7">1</a>) or
      automatically using a “#”-prefixed label. This footnote has a
      label so it can be referred to from multiple places, both as a
      footnote reference (<a class="footnote-reference brackets" href="#label" id="id8">2</a>) and as a hyperlink
      reference
      (<a class="reference internal" href="#label">label</a>).</p>
  </dd>
</dl>
```

0.18 output HTML:

```
<aside class="footnote brackets" id="id6" role="note">
  <span class="label"><span class="fn-bracket">[</span>1<span class="fn-bracket">]</span></span>
  <span class="backrefs">(<a href="#id1" role="doc-backlink">1</a>,<a href="#id7" role="doc-backlink">2</a>)</span>
  <p>A footnote contains body elements, consistently indented by at
    least 3 spaces.</p>
  <p>This is the footnote’s second paragraph.</p>
</aside>
<aside class="footnote brackets" id="label" role="note">
  <span class="label"><span class="fn-bracket">[</span>2<span class="fn-bracket">]</span></span>
  <span class="backrefs">(<a href="#id3" role="doc-backlink">1</a>,<a href="#id8" role="doc-backlink">2</a>)</span>
  <p>Footnotes may be numbered, either manually (as in <a class="footnote-reference brackets" href="#id6" id="id7"
      role="doc-noteref"><span class="fn-bracket">[</span>1<span class="fn-bracket">]</span></a>) or
    automatically using a “#”-prefixed label. This footnote has a
    label so it can be referred to from multiple places, both as a
    footnote reference (<a class="footnote-reference brackets" href="#label" id="id8" role="doc-noteref"><span
        class="fn-bracket">[</span>2<span class="fn-bracket">]</span></a>) and as a hyperlink reference
    (<a class="reference internal" href="#label">label</a>).</p>
</aside>
```

The suggested change to the markup is to generate something like (using only the first aside for this demo):

```
<aside class="footnote brackets" id="id6" role="note">
  <div class="footnote-label">
    <span class="label"><span class="fn-bracket">[</span>1<span class="fn-bracket">]</span></span>
    <span class="backrefs">(<a href="#id1" role="doc-backlink">1</a>,<a href="#id7" role="doc-backlink">2</a>)</span>
  </div>
  <div class="footnote-content">
    <p>A footnote contains body elements, consistently indented by at
      least 3 spaces.</p>
    <p>This is the footnote’s second paragraph.</p>
  </div>
</aside>
```


---

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] #86 Replace recommonmark with myst-docutils

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

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

Release 0.19 (2022-07-05) supports parsing "Markdown" input with 3rd party parsers
  myst, pycmark, or recommonmark.
  Examples:
  Master documents
  
      #> docutils --parser=markdown README.md README.html
                
Included documents:
~~~rst
.. include:: README.md
    :parser: markdown
~~~    
Thank you for your contributions



---

** [feature-requests:#86] Replace recommonmark with myst-docutils**

**Status:** closed-fixed
**Group:** Default
**Created:** Sun Jan 02, 2022 01:26 PM UTC by Chris Sewell
**Last Updated:** Thu Jan 06, 2022 02:07 PM UTC
**Owner:** nobody


Hey guys,

As discussed in https://github.com/readthedocs/recommonmark/issues/221, recommonmark has been officially deprecated in favour of https://github.com/executablebooks/MyST-Parser/.

In myst-parser v0.16, I added first-class support for direct docutils use (as opposed to via sphinx) and introduced the parallel https://pypi.org/project/myst-docutils/ distribution, which is myst-parser but without explicit install requirements on docutils or sphinx, i.e. you can install myst-docutils with any version of docutils and it will work without sphinx installed.

receive(see https://github.com/executablebooks/MyST-Parser/blob/master/CHANGELOG.md#0160---2021-12-06, https://github.com/executablebooks/MyST-Parser/issues/347, and https://myst-parser.readthedocs.io/en/latest/docutils.html) 
receive
receiveIn the master branch (and soon to be myst-docutils v0.17) I have also been working to improve the rigour of the behaviour/testing against this parser.
(as an example, I believe your current recommonmark solution does not actually work properly with code fences, because it does not syntax highlight the code, see: https://github.com/executablebooks/MyST-Parser/pull/478)

The fixture test sets, essentially provide a full specification of the Markdown -> docutils AST conversion (pre-docutils-transforms):

- https://raw.githubusercontent.com/executablebooks/MyST-Parser/master/tests/test_renderers/fixtures/docutil_syntax_elements.md
- https://raw.githubusercontent.com/executablebooks/MyST-Parser/master/tests/test_renderers/fixtures/docutil_roles.md
-  https://raw.githubusercontent.com/executablebooks/MyST-Parser/master/tests/test_renderers/fixtures/docutil_directives.md

and are currently tested in the CI for myst-docutils against docutils v0.16, v0.17 and v0.18: https://github.com/executablebooks/MyST-Parser/runs/4670995311?check_suite_focus=true

I'm also happy to recieve any feedback /  improvement suggestions to facilitate this, and have opened a parallel discussion topic here: https://github.com/executablebooks/MyST-Parser/discussions/487

Cheer,
Chris



---

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] release 0.19 up on pypi

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

Release 0.19 (2022-07-05)
=========================


(Release 0.19b1 (2022-06-21))


* Drop support for Python 2.7, 3.5, and 3.6.


* Output changes:


  HTML5:

    Wrap groups of footnotes in an ``<aside>`` for easier styling.


    The CSS rule ``.footnote-list { display: contents; }`` can be used to
    restore the behaviour of custom CSS styles.


* After package installation, the CLI commands ``python -m docutils`` and
  ``docutils`` start the `generic command line front end tool`__.


  __ docs/user/tools.html#generic-command-line-front-end


* Support parsing "Markdown" input with 3rd party parsers
  myst_, pycmark_, or recommonmark_.


* The default values for the "pep-references", "rfc-base-url",
  and "python-home" `configuration settings`_ now use the "https:" scheme.
  The PEP-writer template's header is updated to fix links and
  resemble the header of official PEPs.


* Various bugfixes and improvements (see HISTORY_).


.. _myst: https://pypi.org/project/myst-docutils
.. _pycmark: https://pypi.org/project/pycmark/
.. _recommonmark: https://pypi.org/project/recommonmark/
.. _configuration settings: docs/user/config.html

Re: [Docutils-develop] docutils prerelease 0.19b1

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

On 2022-07-02, Adam Turner wrote:

> [-- Type: text/plain, Encoding: quoted-printable --]

>>> Another idea would be opening tickets at major contributing projects (MyST, furo or other CSS schemes, ...) and ask for testing with Docutils 0.19b there.

>> I opened several:

> No one has reported errors with Docutils thus far on the ones I opened.

No news is good news (hopefully).

...

>> I mean deprecation warnings from Docutils.

> Ahh, yes. I will pick this up from the Sphinx side and fix the warnings.

Thank you.


I am just working on an "input-encoding handling" proposal. 




> [-- Skipped Type: text/html --]
> [-- Type: text/plain, Encoding: 7bit --]


> [-- Type: text/plain, Encoding: 7bit --]

Re: [Docutils-develop] docutils prerelease 0.19b1

[Adam T. <aat...@ou...>]

>> Another idea would be opening tickets at major contributing projects (MyST, furo or other CSS schemes, ...) and ask for testing with Docutils 0.19b there.

> I opened several:

No one has reported errors with Docutils thus far on the ones I opened.

> I mean deprecation warnings from Docutils.
> We expect some in "stable" Sphinx.
> The Sphinx development version should (ideally) not trigger
> any deprecation warnings but use the documented workarounds/alternatives.
> This ensures that the next stable Sphinx will be ready for the change...

Ahh, yes. I will pick this up from the Sphinx side and fix the warnings.

A

Re: [Docutils-develop] docutils prerelease 0.19b1

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

On 2022-06-26, Adam Turner wrote:
> Dear Günter,

>> Another idea would be opening tickets at major contributing projects (MyST, furo or other CSS schemes, ...) and ask for testing with Docutils 0.19b there.

> I opened several:

Thanks.


>> Could you also have a look, if there are DeprecationWarnings when
>> compiling a project?

> Sorry, I don't understand -- deprecation warnings from Docutils or from
> Sphinx? Do you mean expected warnings that we added or unexpected ones?
> Happy to test, my time during weekdays is limited at the moment though.

I mean deprecation warnings from Docutils.
We expect some in "stable" Sphinx.
The Sphinx development version should (ideally) not trigger
any deprecation warnings but use the documented workarounds/alternatives.
This ensures that the next stable Sphinx will be ready for the change...

Viele Grüße
Günter

Re: [Docutils-develop] docutils prerelease 0.19b1

[Adam T. <aat...@ou...>]

Dear Günter, Engelbert, all,

> Open Points (best solved before releasing 0.19 (final)):
> 
> - input encoding:
> 
>   * Announce a switch of the default to 'utf-8'?
>   * Mark the handling of "input_encoding is None" as provisional?

I would be in favour of both of these, yes.

> - tools / entry-points:
> 
>   * Announce upcoming changes?
> 
>     · name changes (drop extension *.py)

We should announce this, yes.

>     · keep the scripts in /tools but install auto-generated scripts
>       via entry-points (allows modern packager, supports Windows)

For now I think we should keep the scripts in tools/, but perhaps later consider deprecating and removing them.

>     · do not install "exotic" scripts in the binary PATH?

Which would we keep? There is an argument for eventually only installing ``docutils`` into PATH. I agree we should cut down what we put into PATH regardless.

Thanks,
Adam

Re: [Docutils-develop] docutils prerelease 0.19b1

[Adam T. <aat...@ou...>]

Dear Günter,

> Another idea would be opening tickets at major contributing projects (MyST, furo or other CSS schemes, ...) and ask for testing with Docutils 0.19b there.

I opened several:

- Sphinx (covered by me)
- https://github.com/getnikola/nikola/issues/3632
- https://github.com/getpelican/pelican/issues/3017
- https://github.com/executablebooks/MyST-Parser/issues/591
- https://github.com/brechtm/rinohtype/issues/340

Themes:

- https://github.com/pydata/pydata-sphinx-theme/issues/757
- https://github.com/mgeier/insipid-sphinx-theme/issues/101
- https://github.com/pradyunsg/furo/issues/462
- https://github.com/executablebooks/sphinx-book-theme/issues/578
- https://github.com/jbms/sphinx-immaterial/issues/113

> Could you also have a look, if there are DeprecationWarnings when compiling a project?

> I could successfully compile "PyLit" documentation with sphinx-build
> 3.4.3 (from Debian/stable) and Docutils 0.19b (with warnings because of
> the "meta" element changes, but the result looks fine (although not
> polished yet, see https://milde.codeberg.page/PyLit/).

Sorry, I don't understand -- deprecation warnings from Docutils or from Sphinx? Do you mean expected warnings that we added or unexpected ones? Happy to test, my time during weekdays is limited at the moment though.

Thanks,
Adam

Re: [Docutils-develop] docutils prerelease 0.19b1

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

Dear Adam,

On 2022-06-22, Adam Turner wrote:

>> - testing with Sphinx and other third party tools

>>  * contact concerned developers/maintainers Github tickets?

> Speaking in my co-maintainer of Sphinx role, Sphinx passes all tests
> with r9096

This is good news.

> although I still need to do visual testing, I will at
> the weekend. I will also respond to the other questions later on in the
> week.

Another idea would be opening tickets at major contributing projects (MyST,
furo or other CSS schemes, ...) and ask for testing with Docutils 0.19b there.


Could you also have a look, if there are DeprecationWarnings when compiling
a project?

I could successfully compile "PyLit" documentation with sphinx-build
3.4.3 (from Debian/stable) and Docutils 0.19b (with warnings because of
the "meta" element changes, but the result looks fine (although not
polished yet, see https://milde.codeberg.page/PyLit/).


Günter

[Docutils-develop] [docutils:bugs] #452 Release tags seemingly missing from git

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

- **status**: open --> closed-invalid



---

** [bugs:#452] Release tags seemingly missing from git**

**Status:** closed-invalid
**Created:** Sat Jun 25, 2022 01:49 PM UTC by jfbu
**Last Updated:** Sat Jun 25, 2022 08:25 PM UTC
**Owner:** nobody


Apologies if not correct place.  I have on my disk a git clone of the development repo with url ``git://repo.or.cz/docutils.git``.

I have noticed it has no git tags after 0.14:
~~~
$ git tag
0.14
0.14rc1
docutils-
docutils-0.10
docutils-0.11
docutils-0.12
docutils-0.13.1
docutils-0.3.7
docutils-0.3.9
docutils-0.4
docutils-0.5
docutils-0.6
docutils-0.7
docutils-0.8
docutils-0.8.1
docutils-0.9.1
initial
merged_to_nesting
prest-0.3.10
prest-0.3.11
start
~~~
while the HEAD is currently at commit `50048a4046a1b0b5d36eaf2c1fad30618cc2edbc` mapping to revision `9096`, so appears up-to-date.  This makes it impossible to use stuff such as ``git tag --contains 7bbc3e4ed`` for example (where the commit SHA was found by some ``git log --grep findall``).  Now I can probably do a search to find once and for all the commits matching releases... but I am lazy.  Admittedly ``git log --grep release --oneline`` does give me a good start... Hmm, the time devoted to open this ticket I could possibly have used to extract what I need.  But doing stuff with `merge-base --is-ancestor`  is level of magnitude less convenient than ``tag --contains``.  Am I using the right git gateway?


---

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:bugs] #452 Release tags seemingly missing from git

[jfbu <jf...@us...>]

Sorry for noise.  I now did ``git pull --tags``  and indeed tags are fetched, with some messages seemingly indicating some tags were changed upstream.

~~~
>From git://repo.or.cz/docutils
 ! [rejected]            docutils-0.10    -> docutils-0.10  (would clobber existing tag)
 ! [rejected]            docutils-0.11    -> docutils-0.11  (would clobber existing tag)
 ! [rejected]            docutils-0.12    -> docutils-0.12  (would clobber existing tag)
 ! [rejected]            docutils-0.13.1  -> docutils-0.13.1  (would clobber existing tag)
 * [new tag]             docutils-0.14    -> docutils-0.14
 * [new tag]             docutils-0.14.0a -> docutils-0.14.0a
 * [new tag]             docutils-0.14a0  -> docutils-0.14a0
 * [new tag]             docutils-0.14rc1 -> docutils-0.14rc1
 * [new tag]             docutils-0.14rc2 -> docutils-0.14rc2
 * [new tag]             docutils-0.15    -> docutils-0.15
 * [new tag]             docutils-0.16    -> docutils-0.16
 * [new tag]             docutils-0.17    -> docutils-0.17
 * [new tag]             docutils-0.17.1  -> docutils-0.17.1
 * [new tag]             docutils-0.18    -> docutils-0.18
 * [new tag]             docutils-0.18.1  -> docutils-0.18.1
~~~

 My experience of `git` is too limited and never ever before did I have to use ``--tags`` for ``git pull``.  Tags always go fetched automatically from upstream in my earlier experience.  Anyway, I definitely should have tried that before raising this issue.  Please close at your convenience, sorry.


---

** [bugs:#452] Release tags seemingly missing from git**

**Status:** open
**Created:** Sat Jun 25, 2022 01:49 PM UTC by jfbu
**Last Updated:** Sat Jun 25, 2022 03:01 PM UTC
**Owner:** nobody


Apologies if not correct place.  I have on my disk a git clone of the development repo with url ``git://repo.or.cz/docutils.git``.

I have noticed it has no git tags after 0.14:
~~~
$ git tag
0.14
0.14rc1
docutils-
docutils-0.10
docutils-0.11
docutils-0.12
docutils-0.13.1
docutils-0.3.7
docutils-0.3.9
docutils-0.4
docutils-0.5
docutils-0.6
docutils-0.7
docutils-0.8
docutils-0.8.1
docutils-0.9.1
initial
merged_to_nesting
prest-0.3.10
prest-0.3.11
start
~~~
while the HEAD is currently at commit `50048a4046a1b0b5d36eaf2c1fad30618cc2edbc` mapping to revision `9096`, so appears up-to-date.  This makes it impossible to use stuff such as ``git tag --contains 7bbc3e4ed`` for example (where the commit SHA was found by some ``git log --grep findall``).  Now I can probably do a search to find once and for all the commits matching releases... but I am lazy.  Admittedly ``git log --grep release --oneline`` does give me a good start... Hmm, the time devoted to open this ticket I could possibly have used to extract what I need.  But doing stuff with `merge-base --is-ancestor`  is level of magnitude less convenient than ``tag --contains``.  Am I using the right git gateway?


---

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:bugs] #452 Release tags seemingly missing from git

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

but here https://repo.or.cz/docutils.git?a=commit;h=d169015ee0f412cffd69b33654d8a119d99bc0f3 i see a release tag, dont i ?


---

** [bugs:#452] Release tags seemingly missing from git**

**Status:** open
**Created:** Sat Jun 25, 2022 01:49 PM UTC by jfbu
**Last Updated:** Sat Jun 25, 2022 01:49 PM UTC
**Owner:** nobody


Apologies if not correct place.  I have on my disk a git clone of the development repo with url ``git://repo.or.cz/docutils.git``.

I have noticed it has no git tags after 0.14:
~~~
$ git tag
0.14
0.14rc1
docutils-
docutils-0.10
docutils-0.11
docutils-0.12
docutils-0.13.1
docutils-0.3.7
docutils-0.3.9
docutils-0.4
docutils-0.5
docutils-0.6
docutils-0.7
docutils-0.8
docutils-0.8.1
docutils-0.9.1
initial
merged_to_nesting
prest-0.3.10
prest-0.3.11
start
~~~
while the HEAD is currently at commit `50048a4046a1b0b5d36eaf2c1fad30618cc2edbc` mapping to revision `9096`, so appears up-to-date.  This makes it impossible to use stuff such as ``git tag --contains 7bbc3e4ed`` for example (where the commit SHA was found by some ``git log --grep findall``).  Now I can probably do a search to find once and for all the commits matching releases... but I am lazy.  Admittedly ``git log --grep release --oneline`` does give me a good start... Hmm, the time devoted to open this ticket I could possibly have used to extract what I need.  But doing stuff with `merge-base --is-ancestor`  is level of magnitude less convenient than ``tag --contains``.  Am I using the right git gateway?


---

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:bugs] #452 Release tags seemingly missing from git

[jfbu <jf...@us...>]

---

** [bugs:#452] Release tags seemingly missing from git**

**Status:** open
**Created:** Sat Jun 25, 2022 01:49 PM UTC by jfbu
**Last Updated:** Sat Jun 25, 2022 01:49 PM UTC
**Owner:** nobody


Apologies if not correct place.  I have on my disk a git clone of the development repo with url ``git://repo.or.cz/docutils.git``.

I have noticed it has no git tags after 0.14:
~~~
$ git tag
0.14
0.14rc1
docutils-
docutils-0.10
docutils-0.11
docutils-0.12
docutils-0.13.1
docutils-0.3.7
docutils-0.3.9
docutils-0.4
docutils-0.5
docutils-0.6
docutils-0.7
docutils-0.8
docutils-0.8.1
docutils-0.9.1
initial
merged_to_nesting
prest-0.3.10
prest-0.3.11
start
~~~
while the HEAD is currently at commit `50048a4046a1b0b5d36eaf2c1fad30618cc2edbc` mapping to revision `9096`, so appears up-to-date.  This makes it impossible to use stuff such as ``git tag --contains 7bbc3e4ed`` for example (where the commit SHA was found by some ``git log --grep findall``).  Now I can probably do a search to find once and for all the commits matching releases... but I am lazy.  Admittedly ``git log --grep release --oneline`` does give me a good start... Hmm, the time devoted to open this ticket I could possibly have used to extract what I need.  But doing stuff with `merge-base --is-ancestor`  is level of magnitude less convenient than ``tag --contains``.  Am I using the right git gateway?


---

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.

Re: [Docutils-develop] docutils prerelease 0.19b1

[Adam T. <aat...@ou...>]

>> ... several changes happened that made a release necessary

> Thank you for the release.

Seconded.

> Open Points (best solved before releasing 0.19 (final)):

> - testing with Sphinx and other third party tools

>  * contact concerned developers/maintainers Github tickets?

Speaking in my co-maintainer of Sphinx role, Sphinx passes all tests with r9096 [1]_, although I still need to do visual testing, I will at the weekend. I will also respond to the other questions later on in the week.

_[1]: https://github.com/sphinx-doc/sphinx/runs/7013501543

A

Re: [Docutils-develop] docutils prerelease 0.19b1

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

On 2022-06-21, engelbert gruber wrote:

> ... several changes happened that made a release necessary

Thank you for the release.


Some bugs are fixed in commits after the release:

r9089 Stop ignoring the "input-encoding-error-handler" setting/option.

r9090 Fix the wheel naming problem.

r9094 Fix the System Messages in https://docutils.sourceforge.io/HISTORY.html

      Could you upload a fixed version to the web space?


Regarding r9082:
  The script in ``sandbox/infrastructure/version_identifier_parsing.py``
  can be used to update the `docutils.__version_info__`::

    #> cd sandbox/infrastructure
    #> ./version_identifier_parsing.py --change-version-info ../../docutils/docutils/__init__.py

  This feature is fixed in r9096.
  It could be made part of the ``set_version.sh`` script.



Open Points (best solved before releasing 0.19 (final)):

- input encoding:

  * Announce a switch of the default to 'utf-8'?

  * Mark the handling of "input_encoding is None" as provisional?

- tools / entry-points:

  * Announce upcoming changes?

    · name changes (drop extension *.py)

    · keep the scripts in /tools but install auto-generated scripts
      via entry-points (allows modern packager, supports Windows)

    · do not install "exotic" scripts in the binary PATH?

- testing with Sphinx and other third party tools

  * contact concerned developers/maintainers
    Github tickets?


Günter

[Docutils-develop] docutils prerelease 0.19b1

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

Thanks to Günter and Adam several changes happened that made a release
necessary

RELEASE NOTES 0.19

* Drop support for Python 2.7, 3.5, and 3.6.
* Output changes:

  HTML5:

    Wrap groups of footnotes in an ``<aside>`` for easier styling.

    The CSS rule ``.footnote-list { display: contents; }`` can be used to

    restore the behaviour of custom CSS styles.

* After package installation, the CLI commands ``python -m docutils`` and

  ``docutils`` start the `generic command line front end tool`__.

  __ docs/user/tools.html#generic-command-line-front-end

* Support parsing "Markdown" input with 3rd party parsers

  myst_, pycmark_, or recommonmark_.

* The default values for the "pep-references", "rfc-base-url",

  and "python-home" `configuration settings`_ now use the "https:" scheme.

  The PEP-writer template's header is updated to fix links and

  resemble the header of official PEPs.

* Various bugfixes and improvements (see HISTORY_).


install with : pip install docutils --pre

Release 0.19 is planned for july 5th

cheers and all the best
 engelbert

Re: [Docutils-develop] I/O uses default encoding argument

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

On 2022-06-17, Guenter Milde via Docutils-develop wrote:
> On 2022-06-15, Adam Turner wrote:

...


>>> Why do you want to deprecate auto-detection of the input encoding?
>>> * ``encoding='locale'`` does not help if my input files are a mix of
>>>   UTF-8 and latin-1.

...

>> I'm not sure I understand the example you gave as Docutils works on a
>> single file basis. Could you add more context please?

The idea is to try another encoding when UTF-8 fails or when specified in
the document itself.

Use cases would be:

* lazy user with many different rST source files in different encodings
  compiling them on different occasions but not wanting to think about the
  encoding.

* different encodings in files compiled in one run via a Makefile or script
  (e.g. buildhtml.py or similar).


> What I want to keep/restore is the "auto-detect" default behaviour for
> reading/decoding input on Python2 (when opening files under Python 3,
> this only kicks in when the first try rises an UnicodeError):

The attache patches restore the Python2 behaviour 
(auto-detection if FileInput.encoding is None) on Python3 by
(internally) reading the file in binary mode and doing the decoding with
`io.Input.decode()`.

This allows decoding most input without the need to configure an encoding.

Günter

Re: [Docutils-develop] docutils 0.19 timeline

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

On 2022-06-19, engelbert gruber wrote:

> current plan is

> 0.19.0b1 on tuesday june 21

We are now at "0.19b.dev", i.e.
VersionInfo(major=0, minor=19, micro=0, releaselevel='beta', serial=0,
            release=False)

The first beta release version should be 
VersionInfo(major=0, minor=19, micro=0, releaselevel='beta', serial=0,
            release=True)
"0.19b" (or "0.19b0").

> 0.19 on july 5

OK.

In my understanding of our policies, this means

* the repository is closed for commits from now on,

* the repository is open for fixes after the release is done
  and the version identifier set to 
  VersionInfo(major=0, minor=19, micro=0, releaselevel='beta', serial=1,
              release=False)
  i.e. "0.19.b1.dev"

                  
Thank you for undertaking the work,

Günter		  

[Docutils-develop] [docutils:bugs] #450 0.18: New HTML markup for footnotes is difficult to stylise

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

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

Fixed in [r9081]. 



---

** [bugs:#450] 0.18: New HTML markup for footnotes is difficult to stylise**

**Status:** open-fixed
**Created:** Sun Jun 05, 2022 08:28 PM UTC by Pradyun Gedam
**Last Updated:** Sun Jun 19, 2022 02:11 PM UTC
**Owner:** nobody


Docutils 0.18 changed the HTML markup for footnotes/citations generated for rst documents. This changed markup is significantly more difficult to stylise with CSS, in ways that was possible with Docutils 0.17. This has negatively affected HTML themes for Sphinx, since the Sphinx 5 release allows using docutils 0.18, which is preferentially installed by `pip`.

The reasons for this boils down to an inconsistent number of elements inside each `aside`.

1. It's not possible use CSS grid layouts sanely, with this setup.
2. Even if you added multiple rules based on number of elements in the section, it's not possible to know what the 2nd element might be -- which balloons the complexity+size of the stylesheet, if it tries to accomodate for this.

It is theoretically possible to stylise this but it would be on the order of 100s of lines of CSS to get this right, compared to ~20 with 0.17.

Would it be possible to change this markup, to wrap the label & backrefs in a `div` and to wrap the content paragraphs in a separate `div` as well? This would make it possible to stylise this content in ways that were feasible with 0.17, with significantly less complexity in the stylesheets.

---

Sources:

```
[some content that references these footnotes]

.. [1] A footnote contains body elements, consistently indented by at
   least 3 spaces.

   This is the footnote's second paragraph.

.. [#label] Footnotes may be numbered, either manually (as in [1]_) or
   automatically using a "#"-prefixed label.  This footnote has a
   label so it can be referred to from multiple places, both as a
   footnote reference ([#label]_) and as a hyperlink reference
   (label_).

```

0.17 output HTML:

```
<dl class="footnote brackets">
  <dt class="label" id="id6"><span class="brackets">1</span><span class="fn-backref">(<a href="#id1">1</a>,<a
        href="#id7">2</a>)</span></dt>
  <dd>
    <p>A footnote contains body elements, consistently indented by at
      least 3 spaces.</p>
    <p>This is the footnote’s second paragraph.</p>
  </dd>
  <dt class="label" id="label"><span class="brackets">2</span><span class="fn-backref">(<a href="#id3">1</a>,<a
        href="#id8">2</a>)</span></dt>
  <dd>
    <p>Footnotes may be numbered, either manually (as in <a class="footnote-reference brackets" href="#id6"
        id="id7">1</a>) or
      automatically using a “#”-prefixed label. This footnote has a
      label so it can be referred to from multiple places, both as a
      footnote reference (<a class="footnote-reference brackets" href="#label" id="id8">2</a>) and as a hyperlink
      reference
      (<a class="reference internal" href="#label">label</a>).</p>
  </dd>
</dl>
```

0.18 output HTML:

```
<aside class="footnote brackets" id="id6" role="note">
  <span class="label"><span class="fn-bracket">[</span>1<span class="fn-bracket">]</span></span>
  <span class="backrefs">(<a href="#id1" role="doc-backlink">1</a>,<a href="#id7" role="doc-backlink">2</a>)</span>
  <p>A footnote contains body elements, consistently indented by at
    least 3 spaces.</p>
  <p>This is the footnote’s second paragraph.</p>
</aside>
<aside class="footnote brackets" id="label" role="note">
  <span class="label"><span class="fn-bracket">[</span>2<span class="fn-bracket">]</span></span>
  <span class="backrefs">(<a href="#id3" role="doc-backlink">1</a>,<a href="#id8" role="doc-backlink">2</a>)</span>
  <p>Footnotes may be numbered, either manually (as in <a class="footnote-reference brackets" href="#id6" id="id7"
      role="doc-noteref"><span class="fn-bracket">[</span>1<span class="fn-bracket">]</span></a>) or
    automatically using a “#”-prefixed label. This footnote has a
    label so it can be referred to from multiple places, both as a
    footnote reference (<a class="footnote-reference brackets" href="#label" id="id8" role="doc-noteref"><span
        class="fn-bracket">[</span>2<span class="fn-bracket">]</span></a>) and as a hyperlink reference
    (<a class="reference internal" href="#label">label</a>).</p>
</aside>
```

The suggested change to the markup is to generate something like (using only the first aside for this demo):

```
<aside class="footnote brackets" id="id6" role="note">
  <div class="footnote-label">
    <span class="label"><span class="fn-bracket">[</span>1<span class="fn-bracket">]</span></span>
    <span class="backrefs">(<a href="#id1" role="doc-backlink">1</a>,<a href="#id7" role="doc-backlink">2</a>)</span>
  </div>
  <div class="footnote-content">
    <p>A footnote contains body elements, consistently indented by at
      least 3 spaces.</p>
    <p>This is the footnote’s second paragraph.</p>
  </div>
</aside>
```


---

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.