John Snow <[email protected]> writes:

> Separate the specification portion of the documentation section from
> the holistic examples. Avoid naming the section "Examples" because it
> might be confused with the literal case of documenting how code
> examples should themselves be documented.
>
> Signed-off-by: John Snow <[email protected]>
> ---
>  docs/devel/qapi-code-gen.rst | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/docs/devel/qapi-code-gen.rst b/docs/devel/qapi-code-gen.rst
> index f276a2bc9bc..0f66f012be1 100644
> --- a/docs/devel/qapi-code-gen.rst
> +++ b/docs/devel/qapi-code-gen.rst
> @@ -1089,6 +1089,9 @@ Highlighting in non-QMP languages can be accomplished 
> by using the
>  achieved by omitting the language argument.
>  
>  
> +Putting it all together
> +^^^^^^^^^^^^^^^^^^^^^^^
> +
>  Examples of complete definition documentation::
>  
>   ##

This adds another level of headings, level seven:

    Developer Information
        QEMU Build System
            How to use the QAPI code generator
                The QAPI schema language
                    Documentation comments
                        Definition documentation
                            Putting it all together

I'm not thrilled by this depth, to be honest.

Adding the heading makes next to no sense by itself.  However, you add
more headings next to it later in the series, and I believe that's why
you add this one now.  Recommend to mention this in your commit message.

The series' total change to the section structure:

    Introduction
    ============
    The QAPI schema language
    ========================
        Schema syntax
        -------------
        Built-in Types
        --------------
        Include directives
        ------------------
        Pragma directives
        -----------------
        Enumeration types
        -----------------
        Type references and array types
        -------------------------------
        Struct types
        ------------
        Union types
        -----------
        Alternate types
        ---------------
        Commands
        --------
        Events
        ------
        Features
        --------
            Special features
            ~~~~~~~~~~~~~~~~
        Naming rules and reserved names
        -------------------------------
        Downstream extensions
        ---------------------
        Configuring the schema
        ----------------------
        Documentation comments
        ----------------------
            Headings and subheadings
            ~~~~~~~~~~~~~~~~~~~~~~~~
            Documentation markup
            ~~~~~~~~~~~~~~~~~~~~
            Definition documentation
            ~~~~~~~~~~~~~~~~~~~~~~~~
   +            Intro
   +            ^^^^^
   +            Descriptions
   +            ^^^^^^^^^^^^
   +            Tagged sections
   +            ^^^^^^^^^^^^^^^
   +            Returns
   +            ^^^^^^^
   +            Errors
   +            ^^^^^^
   +            Feature Descriptions
   +            ^^^^^^^^^^^^^^^^^^^^
   +            Details
   +            ^^^^^^^
   +            Since
   +            ^^^^^
   +            TODO
   +            ^^^^
   +            Putting it all together
   +            ^^^^^^^^^^^^^^^^^^^^^^^
            Markup pitfalls
            ~~~~~~~~~~~~~~~
    Client JSON Protocol introspection
    ==================================
    Compatibility considerations
    ============================
    Code generation
    ===============
        Code generated for QAPI types
        -----------------------------
        Code generated for visiting QAPI types
        --------------------------------------
        Code generated for commands
        ---------------------------
        Code generated for events
        -------------------------
        Code generated for introspection
        --------------------------------

It's more deeply nested than I'd like, but to avoid that, we'd need a
more invasive restructuring.  Let's not go there now.


Reply via email to