Re: [PATCH 04/13] qapi/parser: preserve indentation in QAPIDoc sections
John Snow writes: > On Fri, Jun 21, 2024 at 2:38 AM Markus Armbruster wrote: [...] >> I'd like you to express more clearly that you're talking about an >> alternative you rejected. Perhaps like this: >> >> block-level constructs such as code blocks, lists, and other such >> markup. >> >> The alternative would be to somehow undo .get_doc_indented()'s >> indentation changes in the new generator. Much messier. >> >> Feel free to add more detail to the last paragraph. >> > > Eh, I just deleted it. I recall running into troubles but I can't > articulate the precise conditions because as you point out, it's a doomed > strategy for other reasons - you can't reconstruct the proper indentation. > > This patch is still the correct way to go, so I don't have to explain my > failures at length in the commit message ... I just like giving people > clues for *why* I decided to implement things a certain way, because I > often find that more instructive than the "how". "Why" tends to be much more useful in a commit message than "how". I should be able to figure out "how" by reading the patch, whereas for "why", I may have to read the author's mind. > In this case, the "why" is > probably more properly summarized as "it's a total shitshow in that > direction, trust me" The right amount of detail is often not obvious. Use your judgement.
Re: [PATCH 04/13] qapi/parser: preserve indentation in QAPIDoc sections
On Fri, Jun 21, 2024 at 2:38 AM Markus Armbruster wrote: > John Snow writes: > > > On Thu, Jun 20, 2024, 11:07 AM Markus Armbruster > wrote: > > > >> John Snow writes: > >> > >> > On Wed, Jun 19, 2024, 8:03 AM Markus Armbruster > wrote: > >> > > >> >> John Snow writes: > >> >> > >> >> > Change get_doc_indented() to preserve indentation on all > subsequent text > >> >> > lines, and create a compatibility dedent() function for qapidoc.py > to > >> >> > remove that indentation. This is being done for the benefit of a > new > >> >> > >> >> Suggest "remove indentation the same way get_doc_indented() did." > >> >> > >> > > >> > Aight. > >> > > >> > > >> >> > qapidoc generator which requires that indentation in argument and > >> >> > features sections are preserved. > >> >> > > >> >> > Prior to this patch, a section like this: > >> >> > > >> >> > ``` > >> >> > @name: lorem ipsum > >> >> >dolor sit amet > >> >> > consectetur adipiscing elit > >> >> > ``` > >> >> > > >> >> > would have its body text be parsed as: > >> >> > >> >> Suggest "parsed into". > >> >> > >> > > >> > Why? (I mean, I'll do it, but I don't see the semantic difference > >> > personally) > >> > > >> > >> "Parse as " vs. "Parse into ". > >> > >> >> > (first and final newline only for presentation) > >> >> > > >> >> > ``` > >> >> > lorem ipsum > >> >> > dolor sit amet > >> >> > consectetur adipiscing elit > >> >> > ``` > >> >> > > >> >> > We want to preserve the indentation for even the first body line > so that > >> >> > the entire block can be parsed directly as rST. This patch would > now > >> >> > parse that segment as: > >> >> > >> >> If you change "parsed as" to "parsed into" above, then do it here, > too. > >> >> > >> >> > > >> >> > ``` > >> >> > lorem ipsum > >> >> >dolor sit amet > >> >> > consectetur adipiscing elit > >> >> > ``` > >> >> > > >> >> > This is helpful for formatting arguments and features as field > lists in > >> >> > rST, where the new generator will format this information as: > >> >> > > >> >> > ``` > >> >> > :arg type name: lorem ipsum > >> >> >dolor sit amet > >> >> > consectetur apidiscing elit > >> >> > ``` > >> >> > > >> >> > ...and can be formed by the simple concatenation of the field list > >> >> > construct and the body text. The indents help preserve the > continuation > >> >> > of a block-level element, and further allow the use of additional > rST > >> >> > block-level constructs such as code blocks, lists, and other such > >> >> > markup. Avoiding reflowing the text conditionally also helps > preserve > >> >> > source line context for better rST error reporting from sphinx > through > >> >> > generated source, too. > >> >> > >> >> What do you mean by "reflowing"? > >> >> > >> > > >> > Poorly phrased, was thinking about emacs too much. I mean munging the > text > >> > post-hoc for the doc generator such that newlines are added or > removed in > >> > the process of re-formatting text to get the proper indentation for > the new > >> > rST form. > >> > > >> > In prototyping, this got messy very quickly and was difficult to > correlate > >> > source line numbers across the transformation. > >> > > >> > It was easier to just not munge the text at all instead of munging it > and > >> > then un-munging it. > >> > > >> > (semantic satiation: munge munge munge munge.) > >> > >> Is this about a possible alternative solution you explored? Keeping > >> .get_doc_indented() as is, and then try to undo its damage? > >> > > > > precisamente. That solution was categorically worse. > > Since .get_doc_indented() removes N spaces of indentation, we'd want to > add back N spaces of indentation. But we can't know N, so I guess we'd > make do with an arbitrary number. Where would reflowing come it? > > I'd like you to express more clearly that you're talking about an > alternative you rejected. Perhaps like this: > > block-level constructs such as code blocks, lists, and other such > markup. > > The alternative would be to somehow undo .get_doc_indented()'s > indentation changes in the new generator. Much messier. > > Feel free to add more detail to the last paragraph. > Eh, I just deleted it. I recall running into troubles but I can't articulate the precise conditions because as you point out, it's a doomed strategy for other reasons - you can't reconstruct the proper indentation. This patch is still the correct way to go, so I don't have to explain my failures at length in the commit message ... I just like giving people clues for *why* I decided to implement things a certain way, because I often find that more instructive than the "how". In this case, the "why" is probably more properly summarized as "it's a total shitshow in that direction, trust me" --js
Re: [PATCH 04/13] qapi/parser: preserve indentation in QAPIDoc sections
John Snow writes: > On Thu, Jun 20, 2024, 11:07 AM Markus Armbruster wrote: > >> John Snow writes: >> >> > On Wed, Jun 19, 2024, 8:03 AM Markus Armbruster wrote: >> > >> >> John Snow writes: >> >> >> >> > Change get_doc_indented() to preserve indentation on all subsequent text >> >> > lines, and create a compatibility dedent() function for qapidoc.py to >> >> > remove that indentation. This is being done for the benefit of a new >> >> >> >> Suggest "remove indentation the same way get_doc_indented() did." >> >> >> > >> > Aight. >> > >> > >> >> > qapidoc generator which requires that indentation in argument and >> >> > features sections are preserved. >> >> > >> >> > Prior to this patch, a section like this: >> >> > >> >> > ``` >> >> > @name: lorem ipsum >> >> >dolor sit amet >> >> > consectetur adipiscing elit >> >> > ``` >> >> > >> >> > would have its body text be parsed as: >> >> >> >> Suggest "parsed into". >> >> >> > >> > Why? (I mean, I'll do it, but I don't see the semantic difference >> > personally) >> > >> >> "Parse as " vs. "Parse into ". >> >> >> > (first and final newline only for presentation) >> >> > >> >> > ``` >> >> > lorem ipsum >> >> > dolor sit amet >> >> > consectetur adipiscing elit >> >> > ``` >> >> > >> >> > We want to preserve the indentation for even the first body line so that >> >> > the entire block can be parsed directly as rST. This patch would now >> >> > parse that segment as: >> >> >> >> If you change "parsed as" to "parsed into" above, then do it here, too. >> >> >> >> > >> >> > ``` >> >> > lorem ipsum >> >> >dolor sit amet >> >> > consectetur adipiscing elit >> >> > ``` >> >> > >> >> > This is helpful for formatting arguments and features as field lists in >> >> > rST, where the new generator will format this information as: >> >> > >> >> > ``` >> >> > :arg type name: lorem ipsum >> >> >dolor sit amet >> >> > consectetur apidiscing elit >> >> > ``` >> >> > >> >> > ...and can be formed by the simple concatenation of the field list >> >> > construct and the body text. The indents help preserve the continuation >> >> > of a block-level element, and further allow the use of additional rST >> >> > block-level constructs such as code blocks, lists, and other such >> >> > markup. Avoiding reflowing the text conditionally also helps preserve >> >> > source line context for better rST error reporting from sphinx through >> >> > generated source, too. >> >> >> >> What do you mean by "reflowing"? >> >> >> > >> > Poorly phrased, was thinking about emacs too much. I mean munging the text >> > post-hoc for the doc generator such that newlines are added or removed in >> > the process of re-formatting text to get the proper indentation for the new >> > rST form. >> > >> > In prototyping, this got messy very quickly and was difficult to correlate >> > source line numbers across the transformation. >> > >> > It was easier to just not munge the text at all instead of munging it and >> > then un-munging it. >> > >> > (semantic satiation: munge munge munge munge.) >> >> Is this about a possible alternative solution you explored? Keeping >> .get_doc_indented() as is, and then try to undo its damage? >> > > precisamente. That solution was categorically worse. Since .get_doc_indented() removes N spaces of indentation, we'd want to add back N spaces of indentation. But we can't know N, so I guess we'd make do with an arbitrary number. Where would reflowing come it? I'd like you to express more clearly that you're talking about an alternative you rejected. Perhaps like this: block-level constructs such as code blocks, lists, and other such markup. The alternative would be to somehow undo .get_doc_indented()'s indentation changes in the new generator. Much messier. Feel free to add more detail to the last paragraph. >> [...]
Re: [PATCH 04/13] qapi/parser: preserve indentation in QAPIDoc sections
On Thu, Jun 20, 2024, 11:07 AM Markus Armbruster wrote: > John Snow writes: > > > On Wed, Jun 19, 2024, 8:03 AM Markus Armbruster > wrote: > > > >> John Snow writes: > >> > >> > Change get_doc_indented() to preserve indentation on all subsequent > text > >> > lines, and create a compatibility dedent() function for qapidoc.py to > >> > remove that indentation. This is being done for the benefit of a new > >> > >> Suggest "remove indentation the same way get_doc_indented() did." > >> > > > > Aight. > > > > > >> > qapidoc generator which requires that indentation in argument and > >> > features sections are preserved. > >> > > >> > Prior to this patch, a section like this: > >> > > >> > ``` > >> > @name: lorem ipsum > >> >dolor sit amet > >> > consectetur adipiscing elit > >> > ``` > >> > > >> > would have its body text be parsed as: > >> > >> Suggest "parsed into". > >> > > > > Why? (I mean, I'll do it, but I don't see the semantic difference > > personally) > > > > "Parse as " vs. "Parse into ". > > >> > (first and final newline only for presentation) > >> > > >> > ``` > >> > lorem ipsum > >> > dolor sit amet > >> > consectetur adipiscing elit > >> > ``` > >> > > >> > We want to preserve the indentation for even the first body line so > that > >> > the entire block can be parsed directly as rST. This patch would now > >> > parse that segment as: > >> > >> If you change "parsed as" to "parsed into" above, then do it here, too. > >> > >> > > >> > ``` > >> > lorem ipsum > >> >dolor sit amet > >> > consectetur adipiscing elit > >> > ``` > >> > > >> > This is helpful for formatting arguments and features as field lists > in > >> > rST, where the new generator will format this information as: > >> > > >> > ``` > >> > :arg type name: lorem ipsum > >> >dolor sit amet > >> > consectetur apidiscing elit > >> > ``` > >> > > >> > ...and can be formed by the simple concatenation of the field list > >> > construct and the body text. The indents help preserve the > continuation > >> > of a block-level element, and further allow the use of additional rST > >> > block-level constructs such as code blocks, lists, and other such > >> > markup. Avoiding reflowing the text conditionally also helps preserve > >> > source line context for better rST error reporting from sphinx through > >> > generated source, too. > >> > >> What do you mean by "reflowing"? > >> > > > > Poorly phrased, was thinking about emacs too much. I mean munging the > text > > post-hoc for the doc generator such that newlines are added or removed in > > the process of re-formatting text to get the proper indentation for the > new > > rST form. > > > > In prototyping, this got messy very quickly and was difficult to > correlate > > source line numbers across the transformation. > > > > It was easier to just not munge the text at all instead of munging it and > > then un-munging it. > > > > (semantic satiation: munge munge munge munge.) > > Is this about a possible alternative solution you explored? Keeping > .get_doc_indented() as is, and then try to undo its damage? > precisamente. That solution was categorically worse. > [...] > >
Re: [PATCH 04/13] qapi/parser: preserve indentation in QAPIDoc sections
John Snow writes: > On Wed, Jun 19, 2024, 8:03 AM Markus Armbruster wrote: > >> John Snow writes: >> >> > Change get_doc_indented() to preserve indentation on all subsequent text >> > lines, and create a compatibility dedent() function for qapidoc.py to >> > remove that indentation. This is being done for the benefit of a new >> >> Suggest "remove indentation the same way get_doc_indented() did." >> > > Aight. > > >> > qapidoc generator which requires that indentation in argument and >> > features sections are preserved. >> > >> > Prior to this patch, a section like this: >> > >> > ``` >> > @name: lorem ipsum >> >dolor sit amet >> > consectetur adipiscing elit >> > ``` >> > >> > would have its body text be parsed as: >> >> Suggest "parsed into". >> > > Why? (I mean, I'll do it, but I don't see the semantic difference > personally) > "Parse as " vs. "Parse into ". >> > (first and final newline only for presentation) >> > >> > ``` >> > lorem ipsum >> > dolor sit amet >> > consectetur adipiscing elit >> > ``` >> > >> > We want to preserve the indentation for even the first body line so that >> > the entire block can be parsed directly as rST. This patch would now >> > parse that segment as: >> >> If you change "parsed as" to "parsed into" above, then do it here, too. >> >> > >> > ``` >> > lorem ipsum >> >dolor sit amet >> > consectetur adipiscing elit >> > ``` >> > >> > This is helpful for formatting arguments and features as field lists in >> > rST, where the new generator will format this information as: >> > >> > ``` >> > :arg type name: lorem ipsum >> >dolor sit amet >> > consectetur apidiscing elit >> > ``` >> > >> > ...and can be formed by the simple concatenation of the field list >> > construct and the body text. The indents help preserve the continuation >> > of a block-level element, and further allow the use of additional rST >> > block-level constructs such as code blocks, lists, and other such >> > markup. Avoiding reflowing the text conditionally also helps preserve >> > source line context for better rST error reporting from sphinx through >> > generated source, too. >> >> What do you mean by "reflowing"? >> > > Poorly phrased, was thinking about emacs too much. I mean munging the text > post-hoc for the doc generator such that newlines are added or removed in > the process of re-formatting text to get the proper indentation for the new > rST form. > > In prototyping, this got messy very quickly and was difficult to correlate > source line numbers across the transformation. > > It was easier to just not munge the text at all instead of munging it and > then un-munging it. > > (semantic satiation: munge munge munge munge.) Is this about a possible alternative solution you explored? Keeping .get_doc_indented() as is, and then try to undo its damage? [...]
Re: [PATCH 04/13] qapi/parser: preserve indentation in QAPIDoc sections
On Wed, Jun 19, 2024, 8:03 AM Markus Armbruster wrote: > John Snow writes: > > > Change get_doc_indented() to preserve indentation on all subsequent text > > lines, and create a compatibility dedent() function for qapidoc.py to > > remove that indentation. This is being done for the benefit of a new > > Suggest "remove indentation the same way get_doc_indented() did." > Aight. > > qapidoc generator which requires that indentation in argument and > > features sections are preserved. > > > > Prior to this patch, a section like this: > > > > ``` > > @name: lorem ipsum > >dolor sit amet > > consectetur adipiscing elit > > ``` > > > > would have its body text be parsed as: > > Suggest "parsed into". > Why? (I mean, I'll do it, but I don't see the semantic difference personally) > > (first and final newline only for presentation) > > > > ``` > > lorem ipsum > > dolor sit amet > > consectetur adipiscing elit > > ``` > > > > We want to preserve the indentation for even the first body line so that > > the entire block can be parsed directly as rST. This patch would now > > parse that segment as: > > If you change "parsed as" to "parsed into" above, then do it here, too. > > > > > ``` > > lorem ipsum > >dolor sit amet > > consectetur adipiscing elit > > ``` > > > > This is helpful for formatting arguments and features as field lists in > > rST, where the new generator will format this information as: > > > > ``` > > :arg type name: lorem ipsum > >dolor sit amet > > consectetur apidiscing elit > > ``` > > > > ...and can be formed by the simple concatenation of the field list > > construct and the body text. The indents help preserve the continuation > > of a block-level element, and further allow the use of additional rST > > block-level constructs such as code blocks, lists, and other such > > markup. Avoiding reflowing the text conditionally also helps preserve > > source line context for better rST error reporting from sphinx through > > generated source, too. > > What do you mean by "reflowing"? > Poorly phrased, was thinking about emacs too much. I mean munging the text post-hoc for the doc generator such that newlines are added or removed in the process of re-formatting text to get the proper indentation for the new rST form. In prototyping, this got messy very quickly and was difficult to correlate source line numbers across the transformation. It was easier to just not munge the text at all instead of munging it and then un-munging it. (semantic satiation: munge munge munge munge.) > > This understandably breaks the existing qapidoc.py; so a new function is > > added there to dedent the text for compatibility. Once the new generator > > is merged, this function will not be needed any longer and can be > > dropped. > > > > I verified this patch changes absolutely nothing by comparing the > > md5sums of the QMP ref html pages both before and after the change, so > > it's certified inert. QAPI test output has been updated to reflect the > > new strategy of preserving indents for rST. > > I think the remainder is unnecessary detail. Drop? > As long as you're convinced it's safe, it's done its job and we thank it for its service > > before: > > > > 69cde3d6f18b0f324badbb447d4381ce manual_before/interop/qemu-ga-ref.html > > 446e9381833def2adc779f1b90f2215f manual_before/interop/qemu-qmp-ref.html > > df0ad6c26cb4c28b85d663fe44609c12 > manual_before/interop/qemu-storage-daemon-qmp-ref.html > > > > after: > > > > 69cde3d6f18b0f324badbb447d4381ce manual/interop/qemu-ga-ref.html > > 446e9381833def2adc779f1b90f2215f manual/interop/qemu-qmp-ref.html > > df0ad6c26cb4c28b85d663fe44609c12 > manual/interop/qemu-storage-daemon-qmp-ref.html > > > > Signed-off-by: John Snow > > --- > > docs/sphinx/qapidoc.py | 29 - > > scripts/qapi/parser.py | 5 +++-- > > tests/qapi-schema/doc-good.out | 32 > > 3 files changed, 43 insertions(+), 23 deletions(-) > > > > diff --git a/docs/sphinx/qapidoc.py b/docs/sphinx/qapidoc.py > > index e675966defa..f2f2005dd5f 100644 > > --- a/docs/sphinx/qapidoc.py > > +++ b/docs/sphinx/qapidoc.py > > @@ -26,6 +26,7 @@ > > > > import os > > import re > > +import textwrap > > > > from docutils import nodes > > from docutils.parsers.rst import Directive, directives > > @@ -53,6 +54,21 @@ > > __version__ = "1.0" > > > > > > +def dedent(text: str) -> str: > > +# Temporary: In service of the new QAPI Sphinx domain, the QAPI doc > > +# parser now preserves indents in args/members/features text. > > +# QAPIDoc does not handle this well, so undo that change here. > > A comment should explain how things are. This one explains how things > have changed. Suggest: > ># Adjust indentation to make description text parse as paragraph. > > If we planned to keep this, we might want to explain in more detail, as > I did in review of v1. But we don't. > > > + > >
Re: [PATCH 04/13] qapi/parser: preserve indentation in QAPIDoc sections
John Snow writes:
> Change get_doc_indented() to preserve indentation on all subsequent text
> lines, and create a compatibility dedent() function for qapidoc.py to
> remove that indentation. This is being done for the benefit of a new
Suggest "remove indentation the same way get_doc_indented() did."
> qapidoc generator which requires that indentation in argument and
> features sections are preserved.
>
> Prior to this patch, a section like this:
>
> ```
> @name: lorem ipsum
>dolor sit amet
> consectetur adipiscing elit
> ```
>
> would have its body text be parsed as:
Suggest "parsed into".
> (first and final newline only for presentation)
>
> ```
> lorem ipsum
> dolor sit amet
> consectetur adipiscing elit
> ```
>
> We want to preserve the indentation for even the first body line so that
> the entire block can be parsed directly as rST. This patch would now
> parse that segment as:
If you change "parsed as" to "parsed into" above, then do it here, too.
>
> ```
> lorem ipsum
>dolor sit amet
> consectetur adipiscing elit
> ```
>
> This is helpful for formatting arguments and features as field lists in
> rST, where the new generator will format this information as:
>
> ```
> :arg type name: lorem ipsum
>dolor sit amet
> consectetur apidiscing elit
> ```
>
> ...and can be formed by the simple concatenation of the field list
> construct and the body text. The indents help preserve the continuation
> of a block-level element, and further allow the use of additional rST
> block-level constructs such as code blocks, lists, and other such
> markup. Avoiding reflowing the text conditionally also helps preserve
> source line context for better rST error reporting from sphinx through
> generated source, too.
What do you mean by "reflowing"?
> This understandably breaks the existing qapidoc.py; so a new function is
> added there to dedent the text for compatibility. Once the new generator
> is merged, this function will not be needed any longer and can be
> dropped.
>
> I verified this patch changes absolutely nothing by comparing the
> md5sums of the QMP ref html pages both before and after the change, so
> it's certified inert. QAPI test output has been updated to reflect the
> new strategy of preserving indents for rST.
I think the remainder is unnecessary detail. Drop?
> before:
>
> 69cde3d6f18b0f324badbb447d4381ce manual_before/interop/qemu-ga-ref.html
> 446e9381833def2adc779f1b90f2215f manual_before/interop/qemu-qmp-ref.html
> df0ad6c26cb4c28b85d663fe44609c12
> manual_before/interop/qemu-storage-daemon-qmp-ref.html
>
> after:
>
> 69cde3d6f18b0f324badbb447d4381ce manual/interop/qemu-ga-ref.html
> 446e9381833def2adc779f1b90f2215f manual/interop/qemu-qmp-ref.html
> df0ad6c26cb4c28b85d663fe44609c12
> manual/interop/qemu-storage-daemon-qmp-ref.html
>
> Signed-off-by: John Snow
> ---
> docs/sphinx/qapidoc.py | 29 -
> scripts/qapi/parser.py | 5 +++--
> tests/qapi-schema/doc-good.out | 32
> 3 files changed, 43 insertions(+), 23 deletions(-)
>
> diff --git a/docs/sphinx/qapidoc.py b/docs/sphinx/qapidoc.py
> index e675966defa..f2f2005dd5f 100644
> --- a/docs/sphinx/qapidoc.py
> +++ b/docs/sphinx/qapidoc.py
> @@ -26,6 +26,7 @@
>
> import os
> import re
> +import textwrap
>
> from docutils import nodes
> from docutils.parsers.rst import Directive, directives
> @@ -53,6 +54,21 @@
> __version__ = "1.0"
>
>
> +def dedent(text: str) -> str:
> +# Temporary: In service of the new QAPI Sphinx domain, the QAPI doc
> +# parser now preserves indents in args/members/features text.
> +# QAPIDoc does not handle this well, so undo that change here.
A comment should explain how things are. This one explains how things
have changed. Suggest:
# Adjust indentation to make description text parse as paragraph.
If we planned to keep this, we might want to explain in more detail, as
I did in review of v1. But we don't.
> +
> +lines = text.splitlines(True)
> +if re.match(r"\s+", lines[0]):
> +# First line is indented; description started on the line after
> +# the name. dedent the whole block.
> +return textwrap.dedent(text)
> +
> +# Descr started on same line. Dedent line 2+.
> +return lines[0] + textwrap.dedent("".join(lines[1:]))
> +
> +
> # Disable black auto-formatter until re-enabled:
> # fmt: off
>
> @@ -176,7 +192,7 @@ def _nodes_for_members(self, doc, what, base=None,
> branches=None):
> term = self._nodes_for_one_member(section.member)
> # TODO drop fallbacks when undocumented members are outlawed
> if section.text:
> -defn = section.text
> +defn = dedent(section.text)
> else:
> defn = [nodes.Text('Not documented')]
>
> @@ -214,7 +230,7 @@ def _nodes_for_enum_values(self, doc):
>
>
