Menu
▾
▴
docutils-develop
|
From: Günter M. <mi...@us...> - 2025-08-26 10:13:07
|
--- **[bugs:#511] Problems with nested parsing and sections.** **Status:** open-fixed **Created:** Tue Aug 26, 2025 10:13 AM UTC by Günter Milde **Last Updated:** Tue Aug 26, 2025 10:13 AM UTC **Owner:** nobody **Attachments:** - [old_nested_parsing.py](https://sourceforge.net/p/docutils/bugs/511/attachment/old_nested_parsing.py) (7.7 kB; text/x-python) In Docutils <= 0.22, parsing a nested content block with `docutils.parsers.rst.state.RSTState.nested_parse()` uses the document-wide "title style hierarchy". With Docutils <=0.21, this method can **loose complete sections** without warning when the `match_titles` argument is True and the nested content block contains sections with a title style that matches a lower section level than the current section level (try the attached test with a Docutils version below 0.22). Docutils itself does not use `nested_parse()` with `match_titles` True and did not test. However, the feature is used by Sphinx and several Sphinx extensions (cf. [bugs:#508], [bugs#509], and https://github.com/sphinx-doc/sphinx/issues/13845). The new section parsing algorithm introduced in Docutils 0.22 fixes the data loss, but sections with a title style that matches a lower section level than the current section level are attached in wrong order: After the nested parsing is complete, the calling parser continues where it left of, messing the order of elements in the doctree (try the attached test with [r10204]). This was fixed in [r10206] at the expense of dropping support for document-wide title styles in nested parsing. As a result, the Sphinx "only" directive (which uses a new section style hierarchy with later re-attachment of the first section) now fails: https://github.com/sphinx-doc/sphinx/issues/13845#issuecomment-3209397215. --- 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. |
|
From: Günter M. <mi...@us...> - 2025-08-26 10:14:50
|
- Attachments has changed: Diff: ~~~~ --- old +++ new @@ -1 +0,0 @@ -old_nested_parsing.py (7.7 kB; text/x-python) ~~~~ --- **[bugs:#511] Problems with nested parsing and sections.** **Status:** open-fixed **Created:** Tue Aug 26, 2025 10:13 AM UTC by Günter Milde **Last Updated:** Tue Aug 26, 2025 10:13 AM UTC **Owner:** nobody In Docutils <= 0.22, parsing a nested content block with `docutils.parsers.rst.state.RSTState.nested_parse()` uses the document-wide "title style hierarchy". With Docutils <=0.21, this method can **loose complete sections** without warning when the `match_titles` argument is True and the nested content block contains sections with a title style that matches a lower section level than the current section level (try the attached test with a Docutils version below 0.22). Docutils itself does not use `nested_parse()` with `match_titles` True and did not test. However, the feature is used by Sphinx and several Sphinx extensions (cf. [bugs:#508], [bugs#509], and https://github.com/sphinx-doc/sphinx/issues/13845). The new section parsing algorithm introduced in Docutils 0.22 fixes the data loss, but sections with a title style that matches a lower section level than the current section level are attached in wrong order: After the nested parsing is complete, the calling parser continues where it left of, messing the order of elements in the doctree (try the attached test with [r10204]). This was fixed in [r10206] at the expense of dropping support for document-wide title styles in nested parsing. As a result, the Sphinx "only" directive (which uses a new section style hierarchy with later re-attachment of the first section) now fails: https://github.com/sphinx-doc/sphinx/issues/13845#issuecomment-3209397215. --- 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. |
|
From: Günter M. <mi...@us...> - 2025-08-26 10:15:52
|
- Attachments has changed: Diff: ~~~~ --- old +++ new @@ -0,0 +1 @@ +old_nested_parsing.py (7.5 kB; text/x-python) ~~~~ --- **[bugs:#511] Problems with nested parsing and sections.** **Status:** open-fixed **Created:** Tue Aug 26, 2025 10:13 AM UTC by Günter Milde **Last Updated:** Tue Aug 26, 2025 10:13 AM UTC **Owner:** nobody **Attachments:** - [old_nested_parsing.py](https://sourceforge.net/p/docutils/bugs/511/attachment/old_nested_parsing.py) (7.5 kB; text/x-python) In Docutils <= 0.22, parsing a nested content block with `docutils.parsers.rst.state.RSTState.nested_parse()` uses the document-wide "title style hierarchy". With Docutils <=0.21, this method can **loose complete sections** without warning when the `match_titles` argument is True and the nested content block contains sections with a title style that matches a lower section level than the current section level (try the attached test with a Docutils version below 0.22). Docutils itself does not use `nested_parse()` with `match_titles` True and did not test. However, the feature is used by Sphinx and several Sphinx extensions (cf. [bugs:#508], [bugs#509], and https://github.com/sphinx-doc/sphinx/issues/13845). The new section parsing algorithm introduced in Docutils 0.22 fixes the data loss, but sections with a title style that matches a lower section level than the current section level are attached in wrong order: After the nested parsing is complete, the calling parser continues where it left of, messing the order of elements in the doctree (try the attached test with [r10204]). This was fixed in [r10206] at the expense of dropping support for document-wide title styles in nested parsing. As a result, the Sphinx "only" directive (which uses a new section style hierarchy with later re-attachment of the first section) now fails: https://github.com/sphinx-doc/sphinx/issues/13845#issuecomment-3209397215. --- 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. |
|
From: Günter M. <mi...@us...> - 2025-08-26 10:25:23
|
- **status**: open-fixed --> pending-remind --- **[bugs:#511] Problems with nested parsing and sections.** **Status:** pending-remind **Created:** Tue Aug 26, 2025 10:13 AM UTC by Günter Milde **Last Updated:** Tue Aug 26, 2025 10:15 AM UTC **Owner:** nobody **Attachments:** - [old_nested_parsing.py](https://sourceforge.net/p/docutils/bugs/511/attachment/old_nested_parsing.py) (7.5 kB; text/x-python) In Docutils <= 0.22, parsing a nested content block with `docutils.parsers.rst.state.RSTState.nested_parse()` uses the document-wide "title style hierarchy". With Docutils <=0.21, this method can **loose complete sections** without warning when the `match_titles` argument is True and the nested content block contains sections with a title style that matches a lower section level than the current section level (try the attached test with a Docutils version below 0.22). Docutils itself does not use `nested_parse()` with `match_titles` True and did not test. However, the feature is used by Sphinx and several Sphinx extensions (cf. [bugs:#508], [bugs#509], and https://github.com/sphinx-doc/sphinx/issues/13845). The new section parsing algorithm introduced in Docutils 0.22 fixes the data loss, but sections with a title style that matches a lower section level than the current section level are attached in wrong order: After the nested parsing is complete, the calling parser continues where it left of, messing the order of elements in the doctree (try the attached test with [r10204]). This was fixed in [r10206] at the expense of dropping support for document-wide title styles in nested parsing. As a result, the Sphinx "only" directive (which uses a new section style hierarchy with later re-attachment of the first section) now fails: https://github.com/sphinx-doc/sphinx/issues/13845#issuecomment-3209397215. --- 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. |
|
From: Günter M. <mi...@us...> - 2025-08-26 10:32:44
|
Element after a section from nested parsing may be invalid.
`parsers.rst.RSTSTate.nested_parse()` with `match_titles=True` (i.e. support for sections) leads to an invalid document tree, if the nested block contains a section but the element following the nested block is not a section.
The [structure model](https://docutils.sourceforge.io/docs/ref/doctree.html#structure-model) ony allows a `<section>` as sibling after a `<section>`.
An invalid doctree can be prevented if the following content is appended to the last nested section instead of its parent. The "nested" directive attempts this but fails if it is called from another nested state machine: In a nested state_machine we cannot access/change the `node` attribute ("insertion point") of the calling state_machine (cf. [r10222]).
A fix using a new attribute to store the parent state machine of nested state machines is attached.
Attachments:
- [0001-New-attribute-to-store-the-parent-state-machine-of-n.patch](https://sourceforge.net/p/docutils/bugs/_discuss/thread/4184882201/239b/attachment/0001-New-attribute-to-store-the-parent-state-machine-of-n.patch) (6.0 kB; text/x-patch)
---
**[bugs:#511] Problems with nested parsing and sections.**
**Status:** pending-remind
**Created:** Tue Aug 26, 2025 10:13 AM UTC by Günter Milde
**Last Updated:** Tue Aug 26, 2025 10:25 AM UTC
**Owner:** nobody
**Attachments:**
- [old_nested_parsing.py](https://sourceforge.net/p/docutils/bugs/511/attachment/old_nested_parsing.py) (7.5 kB; text/x-python)
In Docutils <= 0.22, parsing a nested content block with `docutils.parsers.rst.state.RSTState.nested_parse()` uses the document-wide "title style hierarchy".
With Docutils <=0.21, this method can **loose complete sections** without warning when the `match_titles` argument is True and the nested content block contains sections with a title style that matches a lower section level than the current section level (try the attached test with a Docutils version below 0.22).
Docutils itself does not use `nested_parse()` with `match_titles` True and did not test.
However, the feature is used by Sphinx and several Sphinx extensions (cf. [bugs:#508], [bugs#509], and https://github.com/sphinx-doc/sphinx/issues/13845).
The new section parsing algorithm introduced in Docutils 0.22 fixes the data loss, but sections with a title style that matches a lower section level than the current section level are attached in wrong order: After the nested parsing is complete, the calling parser continues where it left of, messing the order of elements in the doctree (try the attached test with [r10204]).
This was fixed in [r10206] at the expense of dropping support for document-wide title styles in nested parsing.
As a result, the Sphinx "only" directive (which uses a new section style hierarchy with later re-attachment of the first section) now fails: https://github.com/sphinx-doc/sphinx/issues/13845#issuecomment-3209397215.
---
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. |
|
From: Günter M. <mi...@us...> - 2025-09-08 19:09:03
|
The fix is implemented in [r10223]. --- **[bugs:#511] Problems with nested parsing and sections.** **Status:** pending-remind **Created:** Tue Aug 26, 2025 10:13 AM UTC by Günter Milde **Last Updated:** Mon Sep 08, 2025 07:06 PM UTC **Owner:** nobody **Attachments:** - [old_nested_parsing.py](https://sourceforge.net/p/docutils/bugs/511/attachment/old_nested_parsing.py) (7.5 kB; text/x-python) In Docutils <= 0.22, parsing a nested content block with `docutils.parsers.rst.state.RSTState.nested_parse()` uses the document-wide "title style hierarchy". With Docutils <=0.21, this method can **loose complete sections** without warning when the `match_titles` argument is True and the nested content block contains sections with a title style that matches a lower section level than the current section level (try the attached test with a Docutils version below 0.22). Docutils itself does not use `nested_parse()` with `match_titles` True and did not test. However, the feature is used by Sphinx and several Sphinx extensions (cf. [bugs:#508], [bugs:#509], and https://github.com/sphinx-doc/sphinx/issues/13845). The new section parsing algorithm introduced in Docutils 0.22 fixes the data loss, but sections with a title style that matches a lower section level than the current section level are attached in wrong order: After the nested parsing is complete, the calling parser continues where it left of, messing the order of elements in the doctree (try the attached test with [r10204]). This was fixed in [r10206] at the expense of dropping support for document-wide title styles in nested parsing. As a result, the Sphinx "only" directive (which uses a new section style hierarchy with later re-attachment of the first section) now fails: https://github.com/sphinx-doc/sphinx/issues/13861 --- 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. |
|
From: Günter M. <mi...@us...> - 2025-08-26 10:38:46
|
An idea how to fix Sphinx's "only" directive with a new internal attribute "title_style" for the nodes.section element. Attachments: - [0001-New-internal-attribute-nodes.section.title_style.patch](https://sourceforge.net/p/docutils/bugs/_discuss/thread/4184882201/b9f8/attachment/0001-New-internal-attribute-nodes.section.title_style.patch) (8.4 kB; text/x-patch) --- **[bugs:#511] Problems with nested parsing and sections.** **Status:** pending-remind **Created:** Tue Aug 26, 2025 10:13 AM UTC by Günter Milde **Last Updated:** Tue Aug 26, 2025 10:32 AM UTC **Owner:** nobody **Attachments:** - [old_nested_parsing.py](https://sourceforge.net/p/docutils/bugs/511/attachment/old_nested_parsing.py) (7.5 kB; text/x-python) In Docutils <= 0.22, parsing a nested content block with `docutils.parsers.rst.state.RSTState.nested_parse()` uses the document-wide "title style hierarchy". With Docutils <=0.21, this method can **loose complete sections** without warning when the `match_titles` argument is True and the nested content block contains sections with a title style that matches a lower section level than the current section level (try the attached test with a Docutils version below 0.22). Docutils itself does not use `nested_parse()` with `match_titles` True and did not test. However, the feature is used by Sphinx and several Sphinx extensions (cf. [bugs:#508], [bugs#509], and https://github.com/sphinx-doc/sphinx/issues/13845). The new section parsing algorithm introduced in Docutils 0.22 fixes the data loss, but sections with a title style that matches a lower section level than the current section level are attached in wrong order: After the nested parsing is complete, the calling parser continues where it left of, messing the order of elements in the doctree (try the attached test with [r10204]). This was fixed in [r10206] at the expense of dropping support for document-wide title styles in nested parsing. As a result, the Sphinx "only" directive (which uses a new section style hierarchy with later re-attachment of the first section) now fails: https://github.com/sphinx-doc/sphinx/issues/13845#issuecomment-3209397215. --- 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. |
|
From: Günter M. <mi...@us...> - 2025-08-29 21:25:44
|
An alternative idea: nested parse uses the document-wide title style hierarchy if the "node" argument is left at its default value. The result of the nested parsing is directly added to the document (at the "current" node). Sections are appended according to their level. Attachments: - [0001-Support-nested-parsing-with-document-wide-section-ti.patch](https://sourceforge.net/p/docutils/bugs/_discuss/thread/4184882201/2af4/attachment/0001-Support-nested-parsing-with-document-wide-section-ti.patch) (11.8 kB; text/x-patch) --- **[bugs:#511] Problems with nested parsing and sections.** **Status:** pending-remind **Created:** Tue Aug 26, 2025 10:13 AM UTC by Günter Milde **Last Updated:** Tue Aug 26, 2025 10:38 AM UTC **Owner:** nobody **Attachments:** - [old_nested_parsing.py](https://sourceforge.net/p/docutils/bugs/511/attachment/old_nested_parsing.py) (7.5 kB; text/x-python) In Docutils <= 0.22, parsing a nested content block with `docutils.parsers.rst.state.RSTState.nested_parse()` uses the document-wide "title style hierarchy". With Docutils <=0.21, this method can **loose complete sections** without warning when the `match_titles` argument is True and the nested content block contains sections with a title style that matches a lower section level than the current section level (try the attached test with a Docutils version below 0.22). Docutils itself does not use `nested_parse()` with `match_titles` True and did not test. However, the feature is used by Sphinx and several Sphinx extensions (cf. [bugs:#508], [bugs#509], and https://github.com/sphinx-doc/sphinx/issues/13845). The new section parsing algorithm introduced in Docutils 0.22 fixes the data loss, but sections with a title style that matches a lower section level than the current section level are attached in wrong order: After the nested parsing is complete, the calling parser continues where it left of, messing the order of elements in the doctree (try the attached test with [r10204]). This was fixed in [r10206] at the expense of dropping support for document-wide title styles in nested parsing. As a result, the Sphinx "only" directive (which uses a new section style hierarchy with later re-attachment of the first section) now fails: https://github.com/sphinx-doc/sphinx/issues/13845#issuecomment-3209397215. --- 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. |
|
From: engelbert g. <gr...@us...> - 2025-08-31 09:57:58
|
assuming the included document. is complete, has a consistent title
hierarchy
means first title-style is top, next is 2nd asf
standard use case is to include the document at a position where
it's top level is one below the current in the including document
e.g.
section l1
==========
section l2
----------
.. included doc
section l3
==========
section l4
----------
.. including doc
section l2
----------
is there a use case for including and setting a different level, absolute
or relative ?
On Fri, 29 Aug 2025 at 23:25, Günter Milde <mi...@us...>
wrote:
> An alternative idea: nested parse uses the document-wide title style
> hierarchy if the "node" argument is left at its default value. The result
> of the nested parsing is directly added to the document (at the "current"
> node). Sections are appended according to their level.
>
> Attachments:
>
> - 0001-Support-nested-parsing-with-document-wide-section-ti.patch
> <https://sourceforge.net/p/docutils/bugs/_discuss/thread/4184882201/2af4/attachment/0001-Support-nested-parsing-with-document-wide-section-ti.patch>
> (11.8 kB; text/x-patch)
>
> ------------------------------
>
> *[bugs:#511] <https://sourceforge.net/p/docutils/bugs/511/> Problems with
> nested parsing and sections.*
>
> *Status:* pending-remind
> *Created:* Tue Aug 26, 2025 10:13 AM UTC by Günter Milde
> *Last Updated:* Tue Aug 26, 2025 10:38 AM UTC
> *Owner:* nobody
> *Attachments:*
>
> - old_nested_parsing.py
> <https://sourceforge.net/p/docutils/bugs/511/attachment/old_nested_parsing.py>
> (7.5 kB; text/x-python)
>
> In Docutils <= 0.22, parsing a nested content block with
> docutils.parsers.rst.state.RSTState.nested_parse() uses the document-wide
> "title style hierarchy".
>
> With Docutils <=0.21, this method can *loose complete sections* without
> warning when the match_titles argument is True and the nested content
> block contains sections with a title style that matches a lower section
> level than the current section level (try the attached test with a Docutils
> version below 0.22).
>
> Docutils itself does not use nested_parse() with match_titles True and
> did not test.
> However, the feature is used by Sphinx and several Sphinx extensions (cf.
> [bugs:#508] <https://sourceforge.net/p/docutils/bugs/508/>, [bugs#509],
> and https://github.com/sphinx-doc/sphinx/issues/13845).
>
> The new section parsing algorithm introduced in Docutils 0.22 fixes the
> data loss, but sections with a title style that matches a lower section
> level than the current section level are attached in wrong order: After the
> nested parsing is complete, the calling parser continues where it left of,
> messing the order of elements in the doctree (try the attached test with
> [r10204] <https://sourceforge.net/p/docutils/code/10204/>).
>
> This was fixed in [r10206]
> <https://sourceforge.net/p/docutils/code/10206/> at the expense of
> dropping support for document-wide title styles in nested parsing.
> As a result, the Sphinx "only" directive (which uses a new section style
> hierarchy with later re-attachment of the first section) now fails:
> https://github.com/sphinx-doc/sphinx/issues/13845#issuecomment-3209397215.
> ------------------------------
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/docutils/bugs/511/
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
>
---
**[bugs:#511] Problems with nested parsing and sections.**
**Status:** pending-remind
**Created:** Tue Aug 26, 2025 10:13 AM UTC by Günter Milde
**Last Updated:** Fri Aug 29, 2025 09:25 PM UTC
**Owner:** nobody
**Attachments:**
- [old_nested_parsing.py](https://sourceforge.net/p/docutils/bugs/511/attachment/old_nested_parsing.py) (7.5 kB; text/x-python)
In Docutils <= 0.22, parsing a nested content block with `docutils.parsers.rst.state.RSTState.nested_parse()` uses the document-wide "title style hierarchy".
With Docutils <=0.21, this method can **loose complete sections** without warning when the `match_titles` argument is True and the nested content block contains sections with a title style that matches a lower section level than the current section level (try the attached test with a Docutils version below 0.22).
Docutils itself does not use `nested_parse()` with `match_titles` True and did not test.
However, the feature is used by Sphinx and several Sphinx extensions (cf. [bugs:#508], [bugs#509], and https://github.com/sphinx-doc/sphinx/issues/13845).
The new section parsing algorithm introduced in Docutils 0.22 fixes the data loss, but sections with a title style that matches a lower section level than the current section level are attached in wrong order: After the nested parsing is complete, the calling parser continues where it left of, messing the order of elements in the doctree (try the attached test with [r10204]).
This was fixed in [r10206] at the expense of dropping support for document-wide title styles in nested parsing.
As a result, the Sphinx "only" directive (which uses a new section style hierarchy with later re-attachment of the first section) now fails: https://github.com/sphinx-doc/sphinx/issues/13845#issuecomment-3209397215.
---
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. |
|
From: Günter M. <mi...@us...> - 2025-08-31 16:28:38
|
- Description has changed: Diff: ~~~~ --- old +++ new @@ -8,4 +8,4 @@ The new section parsing algorithm introduced in Docutils 0.22 fixes the data loss, but sections with a title style that matches a lower section level than the current section level are attached in wrong order: After the nested parsing is complete, the calling parser continues where it left of, messing the order of elements in the doctree (try the attached test with [r10204]). This was fixed in [r10206] at the expense of dropping support for document-wide title styles in nested parsing. -As a result, the Sphinx "only" directive (which uses a new section style hierarchy with later re-attachment of the first section) now fails: https://github.com/sphinx-doc/sphinx/issues/13845#issuecomment-3209397215. +As a result, the Sphinx "only" directive (which uses a new section style hierarchy with later re-attachment of the first section) now fails: https://github.com/sphinx-doc/sphinx/issues/13861 ~~~~ --- **[bugs:#511] Problems with nested parsing and sections.** **Status:** pending-remind **Created:** Tue Aug 26, 2025 10:13 AM UTC by Günter Milde **Last Updated:** Fri Aug 29, 2025 09:25 PM UTC **Owner:** nobody **Attachments:** - [old_nested_parsing.py](https://sourceforge.net/p/docutils/bugs/511/attachment/old_nested_parsing.py) (7.5 kB; text/x-python) In Docutils <= 0.22, parsing a nested content block with `docutils.parsers.rst.state.RSTState.nested_parse()` uses the document-wide "title style hierarchy". With Docutils <=0.21, this method can **loose complete sections** without warning when the `match_titles` argument is True and the nested content block contains sections with a title style that matches a lower section level than the current section level (try the attached test with a Docutils version below 0.22). Docutils itself does not use `nested_parse()` with `match_titles` True and did not test. However, the feature is used by Sphinx and several Sphinx extensions (cf. [bugs:#508], [bugs#509], and https://github.com/sphinx-doc/sphinx/issues/13845). The new section parsing algorithm introduced in Docutils 0.22 fixes the data loss, but sections with a title style that matches a lower section level than the current section level are attached in wrong order: After the nested parsing is complete, the calling parser continues where it left of, messing the order of elements in the doctree (try the attached test with [r10204]). This was fixed in [r10206] at the expense of dropping support for document-wide title styles in nested parsing. As a result, the Sphinx "only" directive (which uses a new section style hierarchy with later re-attachment of the first section) now fails: https://github.com/sphinx-doc/sphinx/issues/13861 --- 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. |
|
From: Günter M. <mi...@us...> - 2025-09-08 19:06:16
|
- Description has changed: Diff: ~~~~ --- old +++ new @@ -3,7 +3,7 @@ With Docutils <=0.21, this method can **loose complete sections** without warning when the `match_titles` argument is True and the nested content block contains sections with a title style that matches a lower section level than the current section level (try the attached test with a Docutils version below 0.22). Docutils itself does not use `nested_parse()` with `match_titles` True and did not test. -However, the feature is used by Sphinx and several Sphinx extensions (cf. [bugs:#508], [bugs#509], and https://github.com/sphinx-doc/sphinx/issues/13845). +However, the feature is used by Sphinx and several Sphinx extensions (cf. [bugs:#508], [bugs:#509], and https://github.com/sphinx-doc/sphinx/issues/13845). The new section parsing algorithm introduced in Docutils 0.22 fixes the data loss, but sections with a title style that matches a lower section level than the current section level are attached in wrong order: After the nested parsing is complete, the calling parser continues where it left of, messing the order of elements in the doctree (try the attached test with [r10204]). ~~~~ --- **[bugs:#511] Problems with nested parsing and sections.** **Status:** pending-remind **Created:** Tue Aug 26, 2025 10:13 AM UTC by Günter Milde **Last Updated:** Tue Sep 02, 2025 09:54 AM UTC **Owner:** nobody **Attachments:** - [old_nested_parsing.py](https://sourceforge.net/p/docutils/bugs/511/attachment/old_nested_parsing.py) (7.5 kB; text/x-python) In Docutils <= 0.22, parsing a nested content block with `docutils.parsers.rst.state.RSTState.nested_parse()` uses the document-wide "title style hierarchy". With Docutils <=0.21, this method can **loose complete sections** without warning when the `match_titles` argument is True and the nested content block contains sections with a title style that matches a lower section level than the current section level (try the attached test with a Docutils version below 0.22). Docutils itself does not use `nested_parse()` with `match_titles` True and did not test. However, the feature is used by Sphinx and several Sphinx extensions (cf. [bugs:#508], [bugs:#509], and https://github.com/sphinx-doc/sphinx/issues/13845). The new section parsing algorithm introduced in Docutils 0.22 fixes the data loss, but sections with a title style that matches a lower section level than the current section level are attached in wrong order: After the nested parsing is complete, the calling parser continues where it left of, messing the order of elements in the doctree (try the attached test with [r10204]). This was fixed in [r10206] at the expense of dropping support for document-wide title styles in nested parsing. As a result, the Sphinx "only" directive (which uses a new section style hierarchy with later re-attachment of the first section) now fails: https://github.com/sphinx-doc/sphinx/issues/13861 --- 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. |
|
From: Günter M. <mi...@us...> - 2025-09-08 19:18:52
|
Commit [r10226] fixes the [regeression in Sphinx](https://github.com/sphinx-doc/sphinx/issues/13861). In order to correctly support sections in nested parsing, it reverts to using `memo.section_level` to keep record of the current section level. This is cumbersome and error prone because it needs to be updated with every switch of the current node. The attached patch implements an alternative: Store the difference between the intended start level of nested parsing and the number of parents of the base node in the new attribute `section_level_offset`. Use it to correct the section level determined via `node.section_hierarchy()`. Attachments: - [0001-rST-parser-Use-section_level_offset-instead-of-memo..patch](https://sourceforge.net/p/docutils/bugs/_discuss/thread/4184882201/424c/attachment/0001-rST-parser-Use-section_level_offset-instead-of-memo..patch) (7.0 kB; text/x-patch) --- **[bugs:#511] Problems with nested parsing and sections.** **Status:** pending-remind **Created:** Tue Aug 26, 2025 10:13 AM UTC by Günter Milde **Last Updated:** Mon Sep 08, 2025 07:09 PM UTC **Owner:** nobody **Attachments:** - [old_nested_parsing.py](https://sourceforge.net/p/docutils/bugs/511/attachment/old_nested_parsing.py) (7.5 kB; text/x-python) In Docutils <= 0.22, parsing a nested content block with `docutils.parsers.rst.state.RSTState.nested_parse()` uses the document-wide "title style hierarchy". With Docutils <=0.21, this method can **loose complete sections** without warning when the `match_titles` argument is True and the nested content block contains sections with a title style that matches a lower section level than the current section level (try the attached test with a Docutils version below 0.22). Docutils itself does not use `nested_parse()` with `match_titles` True and did not test. However, the feature is used by Sphinx and several Sphinx extensions (cf. [bugs:#508], [bugs:#509], and https://github.com/sphinx-doc/sphinx/issues/13845). The new section parsing algorithm introduced in Docutils 0.22 fixes the data loss, but sections with a title style that matches a lower section level than the current section level are attached in wrong order: After the nested parsing is complete, the calling parser continues where it left of, messing the order of elements in the doctree (try the attached test with [r10204]). This was fixed in [r10206] at the expense of dropping support for document-wide title styles in nested parsing. As a result, the Sphinx "only" directive (which uses a new section style hierarchy with later re-attachment of the first section) now fails: https://github.com/sphinx-doc/sphinx/issues/13861 --- 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. |
|
From: Günter M. <mi...@us...> - 2025-09-13 08:31:46
|
Applied in [r10229]. --- **[bugs:#511] Problems with nested parsing and sections.** **Status:** pending-remind **Created:** Tue Aug 26, 2025 10:13 AM UTC by Günter Milde **Last Updated:** Mon Sep 08, 2025 07:18 PM UTC **Owner:** nobody **Attachments:** - [old_nested_parsing.py](https://sourceforge.net/p/docutils/bugs/511/attachment/old_nested_parsing.py) (7.5 kB; text/x-python) In Docutils <= 0.22, parsing a nested content block with `docutils.parsers.rst.state.RSTState.nested_parse()` uses the document-wide "title style hierarchy". With Docutils <=0.21, this method can **loose complete sections** without warning when the `match_titles` argument is True and the nested content block contains sections with a title style that matches a lower section level than the current section level (try the attached test with a Docutils version below 0.22). Docutils itself does not use `nested_parse()` with `match_titles` True and did not test. However, the feature is used by Sphinx and several Sphinx extensions (cf. [bugs:#508], [bugs:#509], and https://github.com/sphinx-doc/sphinx/issues/13845). The new section parsing algorithm introduced in Docutils 0.22 fixes the data loss, but sections with a title style that matches a lower section level than the current section level are attached in wrong order: After the nested parsing is complete, the calling parser continues where it left of, messing the order of elements in the doctree (try the attached test with [r10204]). This was fixed in [r10206] at the expense of dropping support for document-wide title styles in nested parsing. As a result, the Sphinx "only" directive (which uses a new section style hierarchy with later re-attachment of the first section) now fails: https://github.com/sphinx-doc/sphinx/issues/13861 --- 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. |
|
From: Günter M. <mi...@us...> - 2025-09-13 08:33:57
|
The remaining issue is a way to tell `RSTState.nested_parse()` that it shall use a new, separate title style hierarchy for section headings (similar to Sphinx `nested_parse_to_nodes()`). --- **[bugs:#511] Problems with nested parsing and sections.** **Status:** pending-remind **Created:** Tue Aug 26, 2025 10:13 AM UTC by Günter Milde **Last Updated:** Sat Sep 13, 2025 08:31 AM UTC **Owner:** nobody **Attachments:** - [old_nested_parsing.py](https://sourceforge.net/p/docutils/bugs/511/attachment/old_nested_parsing.py) (7.5 kB; text/x-python) In Docutils <= 0.22, parsing a nested content block with `docutils.parsers.rst.state.RSTState.nested_parse()` uses the document-wide "title style hierarchy". With Docutils <=0.21, this method can **loose complete sections** without warning when the `match_titles` argument is True and the nested content block contains sections with a title style that matches a lower section level than the current section level (try the attached test with a Docutils version below 0.22). Docutils itself does not use `nested_parse()` with `match_titles` True and did not test. However, the feature is used by Sphinx and several Sphinx extensions (cf. [bugs:#508], [bugs:#509], and https://github.com/sphinx-doc/sphinx/issues/13845). The new section parsing algorithm introduced in Docutils 0.22 fixes the data loss, but sections with a title style that matches a lower section level than the current section level are attached in wrong order: After the nested parsing is complete, the calling parser continues where it left of, messing the order of elements in the doctree (try the attached test with [r10204]). This was fixed in [r10206] at the expense of dropping support for document-wide title styles in nested parsing. As a result, the Sphinx "only" directive (which uses a new section style hierarchy with later re-attachment of the first section) now fails: https://github.com/sphinx-doc/sphinx/issues/13861 --- 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. |
Thanks for helping keep SourceForge clean.
X