2021-02-01 22:37:39 +03:00
|
|
|
module ./builtin
|
2018-02-11 12:35:54 +03:00
|
|
|
object q_empty
|
2018-12-13 15:37:05 +03:00
|
|
|
enum QType
|
|
|
|
member none
|
|
|
|
member qnull
|
|
|
|
member qnum
|
|
|
|
member qstring
|
|
|
|
member qdict
|
|
|
|
member qlist
|
|
|
|
member qbool
|
2018-02-11 12:35:55 +03:00
|
|
|
module doc-good.json
|
2018-12-13 15:37:05 +03:00
|
|
|
enum Enum
|
|
|
|
member one
|
2021-08-04 11:31:05 +03:00
|
|
|
if IFONE
|
2021-10-25 07:24:02 +03:00
|
|
|
feature enum-member-feat
|
2018-12-13 15:37:05 +03:00
|
|
|
member two
|
2021-08-04 11:31:05 +03:00
|
|
|
if IFCOND
|
2020-03-17 14:54:37 +03:00
|
|
|
feature enum-feat
|
2017-03-20 16:11:54 +03:00
|
|
|
object Base
|
|
|
|
member base1: Enum optional=False
|
tests/qapi-schema: Hide OrderedDict in test output
Since commit 5d83b9a130 "qapi: replace if condition list with dict
{'all': [...]}", we represent if conditionals as trees consisting of
OrderedDict, list and str. This results in less than legible test
output. For instance:
if OrderedDict([('not', OrderedDict([('any', [OrderedDict([('not', 'TEST_IF_EVT')]), OrderedDict([('not', 'TEST_IF_STRUCT')])])]))])
We intend to replace OrderedDict by dict when we get Python 3.7, which
will result in more legible output:
if {'not': {'any': [{'not': 'TEST_IF_EVT'}, {'not': 'TEST_IF_STRUCT'}]}}
Can't wait: put in a hack to get that now, with a comment to revert it
when we replace OrderedDict.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20210831123809.1107782-11-armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2021-08-31 15:38:07 +03:00
|
|
|
if {'all': ['IFALL1', 'IFALL2']}
|
2018-02-11 12:35:54 +03:00
|
|
|
object Variant1
|
|
|
|
member var1: str optional=False
|
2021-08-04 11:31:05 +03:00
|
|
|
if IFSTR
|
2020-03-17 14:54:45 +03:00
|
|
|
feature member-feat
|
2019-10-18 11:14:53 +03:00
|
|
|
feature variant1-feat
|
2018-02-11 12:35:54 +03:00
|
|
|
object Variant2
|
2017-03-20 16:11:54 +03:00
|
|
|
object Object
|
|
|
|
base Base
|
|
|
|
tag base1
|
|
|
|
case one: Variant1
|
|
|
|
case two: Variant2
|
tests/qapi-schema: Hide OrderedDict in test output
Since commit 5d83b9a130 "qapi: replace if condition list with dict
{'all': [...]}", we represent if conditionals as trees consisting of
OrderedDict, list and str. This results in less than legible test
output. For instance:
if OrderedDict([('not', OrderedDict([('any', [OrderedDict([('not', 'TEST_IF_EVT')]), OrderedDict([('not', 'TEST_IF_STRUCT')])])]))])
We intend to replace OrderedDict by dict when we get Python 3.7, which
will result in more legible output:
if {'not': {'any': [{'not': 'TEST_IF_EVT'}, {'not': 'TEST_IF_STRUCT'}]}}
Can't wait: put in a hack to get that now, with a comment to revert it
when we replace OrderedDict.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20210831123809.1107782-11-armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2021-08-31 15:38:07 +03:00
|
|
|
if {'any': ['IFONE', 'IFTWO']}
|
2020-03-17 14:54:37 +03:00
|
|
|
feature union-feat1
|
2019-10-24 14:02:21 +03:00
|
|
|
alternate Alternate
|
|
|
|
tag type
|
|
|
|
case i: int
|
|
|
|
case b: bool
|
tests/qapi-schema: Hide OrderedDict in test output
Since commit 5d83b9a130 "qapi: replace if condition list with dict
{'all': [...]}", we represent if conditionals as trees consisting of
OrderedDict, list and str. This results in less than legible test
output. For instance:
if OrderedDict([('not', OrderedDict([('any', [OrderedDict([('not', 'TEST_IF_EVT')]), OrderedDict([('not', 'TEST_IF_STRUCT')])])]))])
We intend to replace OrderedDict by dict when we get Python 3.7, which
will result in more legible output:
if {'not': {'any': [{'not': 'TEST_IF_EVT'}, {'not': 'TEST_IF_STRUCT'}]}}
Can't wait: put in a hack to get that now, with a comment to revert it
when we replace OrderedDict.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20210831123809.1107782-11-armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2021-08-31 15:38:07 +03:00
|
|
|
if {'not': {'any': ['IFONE', 'IFTWO']}}
|
2020-03-17 14:54:37 +03:00
|
|
|
feature alt-feat
|
2017-03-20 16:11:54 +03:00
|
|
|
object q_obj_cmd-arg
|
|
|
|
member arg1: int optional=False
|
|
|
|
member arg2: str optional=True
|
|
|
|
member arg3: bool optional=False
|
2018-02-11 12:35:54 +03:00
|
|
|
command cmd q_obj_cmd-arg -> Object
|
2019-10-18 11:14:50 +03:00
|
|
|
gen=True success_response=True boxed=False oob=False preconfig=False
|
2019-10-18 11:14:53 +03:00
|
|
|
feature cmd-feat1
|
|
|
|
feature cmd-feat2
|
2018-02-11 12:35:54 +03:00
|
|
|
command cmd-boxed Object -> None
|
2019-10-18 11:14:50 +03:00
|
|
|
gen=True success_response=True boxed=True oob=False preconfig=False
|
2019-10-18 11:14:53 +03:00
|
|
|
feature cmd-feat1
|
|
|
|
feature cmd-feat2
|
2021-03-23 12:40:10 +03:00
|
|
|
event EVT_BOXED Object
|
2019-10-24 14:02:20 +03:00
|
|
|
boxed=True
|
2020-03-17 14:54:37 +03:00
|
|
|
feature feat3
|
2017-03-20 16:11:54 +03:00
|
|
|
doc freeform
|
|
|
|
body=
|
|
|
|
= Section
|
2020-03-20 12:18:05 +03:00
|
|
|
doc freeform
|
|
|
|
body=
|
2017-03-20 16:11:54 +03:00
|
|
|
== Subsection
|
|
|
|
|
2020-09-25 19:23:07 +03:00
|
|
|
*with emphasis*
|
2017-03-20 16:11:54 +03:00
|
|
|
@var {in braces}
|
2020-09-25 19:22:58 +03:00
|
|
|
|
2017-03-20 16:11:54 +03:00
|
|
|
* List item one
|
2020-09-25 19:22:58 +03:00
|
|
|
* Two, multiple
|
2020-09-25 19:22:59 +03:00
|
|
|
lines
|
2017-03-20 16:11:54 +03:00
|
|
|
|
2020-09-25 19:22:58 +03:00
|
|
|
* Three
|
2020-09-25 19:22:59 +03:00
|
|
|
Still in list
|
2017-03-20 16:11:54 +03:00
|
|
|
|
|
|
|
Not in list
|
2020-09-25 19:22:58 +03:00
|
|
|
|
2017-03-20 16:11:54 +03:00
|
|
|
- Second list
|
2020-09-25 19:22:59 +03:00
|
|
|
Note: still in list
|
2017-03-20 16:11:54 +03:00
|
|
|
|
|
|
|
Note: not in list
|
2020-09-25 19:22:58 +03:00
|
|
|
|
2017-03-20 16:11:54 +03:00
|
|
|
1. Third list
|
2020-09-25 19:22:59 +03:00
|
|
|
is numbered
|
2017-03-20 16:11:54 +03:00
|
|
|
|
2020-09-25 19:22:58 +03:00
|
|
|
2. another item
|
2017-03-20 16:11:54 +03:00
|
|
|
|
|
|
|
Returns: the King
|
|
|
|
Since: the first age
|
|
|
|
Notes:
|
|
|
|
|
|
|
|
1. Lorem ipsum dolor sit amet
|
|
|
|
|
|
|
|
2. Ut enim ad minim veniam
|
|
|
|
|
|
|
|
Duis aute irure dolor
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
-> in
|
|
|
|
<- out
|
|
|
|
Examples:
|
|
|
|
- *verbatim*
|
|
|
|
- {braces}
|
|
|
|
doc symbol=Enum
|
|
|
|
body=
|
2017-10-02 17:13:35 +03:00
|
|
|
|
2017-03-20 16:11:54 +03:00
|
|
|
arg=one
|
2023-04-28 13:54:22 +03:00
|
|
|
The _one_ {and only}, description on the same line
|
2017-03-20 16:11:54 +03:00
|
|
|
arg=two
|
|
|
|
|
2020-03-17 14:54:37 +03:00
|
|
|
feature=enum-feat
|
|
|
|
Also _one_ {and only}
|
2021-10-25 07:24:02 +03:00
|
|
|
feature=enum-member-feat
|
|
|
|
a member feature
|
2017-10-02 17:13:37 +03:00
|
|
|
section=None
|
2017-03-20 16:11:54 +03:00
|
|
|
@two is undocumented
|
|
|
|
doc symbol=Base
|
|
|
|
body=
|
|
|
|
|
|
|
|
arg=base1
|
2024-06-27 01:21:11 +03:00
|
|
|
description starts on a new line,
|
|
|
|
minimally indented
|
2017-03-20 16:11:54 +03:00
|
|
|
doc symbol=Variant1
|
|
|
|
body=
|
|
|
|
A paragraph
|
|
|
|
|
2023-04-28 13:54:22 +03:00
|
|
|
Another paragraph
|
2023-04-28 13:54:21 +03:00
|
|
|
|
|
|
|
@var1 is undocumented
|
2017-03-20 16:11:54 +03:00
|
|
|
arg=var1
|
|
|
|
|
2019-10-24 14:02:22 +03:00
|
|
|
feature=variant1-feat
|
|
|
|
a feature
|
2020-03-17 14:54:45 +03:00
|
|
|
feature=member-feat
|
|
|
|
a member feature
|
2017-03-20 16:11:54 +03:00
|
|
|
doc symbol=Variant2
|
|
|
|
body=
|
|
|
|
|
|
|
|
doc symbol=Object
|
|
|
|
body=
|
|
|
|
|
2020-03-17 14:54:37 +03:00
|
|
|
feature=union-feat1
|
|
|
|
a feature
|
2019-10-24 14:02:21 +03:00
|
|
|
doc symbol=Alternate
|
|
|
|
body=
|
|
|
|
|
|
|
|
arg=i
|
2023-04-28 13:54:22 +03:00
|
|
|
description starts on the same line
|
2024-06-27 01:21:11 +03:00
|
|
|
remainder indented the same
|
|
|
|
@b is undocumented
|
2019-10-24 14:02:21 +03:00
|
|
|
arg=b
|
|
|
|
|
2020-03-17 14:54:37 +03:00
|
|
|
feature=alt-feat
|
|
|
|
a feature
|
2017-03-20 16:11:54 +03:00
|
|
|
doc freeform
|
|
|
|
body=
|
|
|
|
== Another subsection
|
|
|
|
doc symbol=cmd
|
|
|
|
body=
|
|
|
|
|
|
|
|
arg=arg1
|
2024-06-27 01:21:11 +03:00
|
|
|
description starts on a new line,
|
|
|
|
indented
|
2017-03-20 16:11:54 +03:00
|
|
|
arg=arg2
|
qapi: Relax doc string @name: description indentation rules
The QAPI schema doc comment language provides special syntax for
command and event arguments, struct and union members, alternate
branches, enumeration values, and features: descriptions starting with
"@name:".
By convention, we format them like this:
# @name: Lorem ipsum dolor sit amet, consectetur adipiscing elit,
# sed do eiusmod tempor incididunt ut labore et dolore
# magna aliqua.
Okay for names as short as "name", but we have much longer ones. Their
description gets squeezed against the right margin, like this:
# @dirty-sync-missed-zero-copy: Number of times dirty RAM synchronization could
# not avoid copying dirty pages. This is between
# 0 and @dirty-sync-count * @multifd-channels.
# (since 7.1)
The description text is effectively just 50 characters wide. Easy
enough to read, but can be cumbersome to write.
The awkward squeeze against the right margin makes people go beyond it,
which produces two undesirables: arguments about style, and descriptions
that are unnecessarily hard to read, like this one:
# @postcopy-vcpu-blocktime: list of the postcopy blocktime per vCPU. This is
# only present when the postcopy-blocktime migration capability
# is enabled. (Since 3.0)
We could instead format it like
# @postcopy-vcpu-blocktime:
# list of the postcopy blocktime per vCPU. This is only present
# when the postcopy-blocktime migration capability is
# enabled. (Since 3.0)
or, since the commit before previous, like
# @postcopy-vcpu-blocktime:
# list of the postcopy blocktime per vCPU. This is only present
# when the postcopy-blocktime migration capability is
# enabled. (Since 3.0)
However, I'd rather have
# @postcopy-vcpu-blocktime: list of the postcopy blocktime per vCPU.
# This is only present when the postcopy-blocktime migration
# capability is enabled. (Since 3.0)
because this is how rST field and option lists work.
To get this, we need to let the first non-blank line after the
"@name:" line determine expected indentation.
This fills up the indentation pitfall mentioned in
docs/devel/qapi-code-gen.rst. A related pitfall still exists. Update
the text to show it.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20230428105429.1687850-14-armbru@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
[Work around lack of walrus operator in Python 3.7 and older]
2023-04-28 13:54:25 +03:00
|
|
|
description starts on the same line
|
2024-06-27 01:21:11 +03:00
|
|
|
remainder indented differently
|
2017-03-20 16:11:54 +03:00
|
|
|
arg=arg3
|
|
|
|
|
2019-10-24 14:02:22 +03:00
|
|
|
feature=cmd-feat1
|
|
|
|
a feature
|
|
|
|
feature=cmd-feat2
|
|
|
|
another feature
|
qapi: convert "Note" sections to plain rST
We do not need a dedicated section for notes. By eliminating a specially
parsed section, these notes can be treated as normal rST paragraphs in
the new QMP reference manual, and can be placed and styled much more
flexibly.
Convert all existing "Note" and "Notes" sections to pure rST. As part of
the conversion, capitalize the first letter of each sentence and add
trailing punctuation where appropriate to ensure notes look sensible and
consistent in rendered HTML documentation. Markup is also re-aligned to
the de-facto standard of 3 spaces for directives.
Update docs/devel/qapi-code-gen.rst to reflect the new paradigm, and
update the QAPI parser to prohibit "Note" sections while suggesting a
new syntax. The exact formatting to use is a matter of taste, but a good
candidate is simply:
.. note:: lorem ipsum ...
... dolor sit amet ...
... consectetur adipiscing elit ...
... but there are other choices, too. The Sphinx readthedocs theme
offers theming for the following forms (capitalization unimportant); all
are adorned with a (!) symbol () in the title bar for rendered HTML
docs.
See
https://sphinx-rtd-theme.readthedocs.io/en/stable/demo/demo.html#admonitions
for examples of each directive/admonition in use.
These are rendered in orange:
.. Attention:: ...
.. Caution:: ...
.. WARNING:: ...
These are rendered in red:
.. DANGER:: ...
.. Error:: ...
These are rendered in green:
.. Hint:: ...
.. Important:: ...
.. Tip:: ...
These are rendered in blue:
.. Note:: ...
.. admonition:: custom title
admonition body text
This patch uses ".. note::" almost everywhere, with just two "caution"
directives. Several instances of "Notes:" have been converted to
merely ".. note::", or multiple ".. note::" where appropriate.
".. admonition:: notes" is used in a few places where we had an
ordered list of multiple notes that would not make sense as
standalone/separate admonitions. Two "Note:" following "Example:"
have been turned into ordinary paragraphs within the example.
NOTE: Because qapidoc.py does not attempt to preserve source ordering of
sections, the conversion of Notes from a "tagged section" to an
"untagged section" means that rendering order for some notes *may
change* as a result of this patch. The forthcoming qapidoc.py rewrite
strictly preserves source ordering in the rendered documentation, so
this issue will be rectified in the new generator.
Signed-off-by: John Snow <jsnow@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com> [for block*.json]
Message-ID: <20240626222128.406106-11-jsnow@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Commit message clarified slightly, period added to one more note]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2024-06-27 01:21:16 +03:00
|
|
|
section=None
|
|
|
|
.. note:: @arg3 is undocumented
|
2017-03-20 16:11:54 +03:00
|
|
|
section=Returns
|
|
|
|
@Object
|
2024-02-27 14:39:11 +03:00
|
|
|
section=Errors
|
|
|
|
some
|
2017-03-20 16:11:54 +03:00
|
|
|
section=TODO
|
|
|
|
frobnicate
|
qapi: convert "Note" sections to plain rST
We do not need a dedicated section for notes. By eliminating a specially
parsed section, these notes can be treated as normal rST paragraphs in
the new QMP reference manual, and can be placed and styled much more
flexibly.
Convert all existing "Note" and "Notes" sections to pure rST. As part of
the conversion, capitalize the first letter of each sentence and add
trailing punctuation where appropriate to ensure notes look sensible and
consistent in rendered HTML documentation. Markup is also re-aligned to
the de-facto standard of 3 spaces for directives.
Update docs/devel/qapi-code-gen.rst to reflect the new paradigm, and
update the QAPI parser to prohibit "Note" sections while suggesting a
new syntax. The exact formatting to use is a matter of taste, but a good
candidate is simply:
.. note:: lorem ipsum ...
... dolor sit amet ...
... consectetur adipiscing elit ...
... but there are other choices, too. The Sphinx readthedocs theme
offers theming for the following forms (capitalization unimportant); all
are adorned with a (!) symbol () in the title bar for rendered HTML
docs.
See
https://sphinx-rtd-theme.readthedocs.io/en/stable/demo/demo.html#admonitions
for examples of each directive/admonition in use.
These are rendered in orange:
.. Attention:: ...
.. Caution:: ...
.. WARNING:: ...
These are rendered in red:
.. DANGER:: ...
.. Error:: ...
These are rendered in green:
.. Hint:: ...
.. Important:: ...
.. Tip:: ...
These are rendered in blue:
.. Note:: ...
.. admonition:: custom title
admonition body text
This patch uses ".. note::" almost everywhere, with just two "caution"
directives. Several instances of "Notes:" have been converted to
merely ".. note::", or multiple ".. note::" where appropriate.
".. admonition:: notes" is used in a few places where we had an
ordered list of multiple notes that would not make sense as
standalone/separate admonitions. Two "Note:" following "Example:"
have been turned into ordinary paragraphs within the example.
NOTE: Because qapidoc.py does not attempt to preserve source ordering of
sections, the conversion of Notes from a "tagged section" to an
"untagged section" means that rendering order for some notes *may
change* as a result of this patch. The forthcoming qapidoc.py rewrite
strictly preserves source ordering in the rendered documentation, so
this issue will be rectified in the new generator.
Signed-off-by: John Snow <jsnow@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com> [for block*.json]
Message-ID: <20240626222128.406106-11-jsnow@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Commit message clarified slightly, period added to one more note]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2024-06-27 01:21:16 +03:00
|
|
|
section=None
|
|
|
|
.. admonition:: Notes
|
|
|
|
|
2024-06-27 01:21:11 +03:00
|
|
|
- Lorem ipsum dolor sit amet
|
|
|
|
- Ut enim ad minim veniam
|
2017-03-20 16:11:54 +03:00
|
|
|
|
2024-06-27 01:21:11 +03:00
|
|
|
Duis aute irure dolor
|
qapi: remove "Example" doc section
Fully eliminate the "Example" sections in QAPI doc blocks now that they
have all been converted to arbitrary rST syntax using the
".. qmp-example::" directive. Update tests to match.
Migrating to the new syntax
---------------------------
The old "Example:" or "Examples:" section syntax is now caught as an
error, but "Example::" is stil permitted as explicit rST syntax for an
un-lexed, generic preformatted text block.
('Example' is not special in this case, any sentence that ends with "::"
will start an indented code block in rST.)
Arbitrary rST for Examples is now possible, but it's strongly
recommended that documentation authors use the ".. qmp-example::"
directive for consistent visual formatting in rendered HTML docs. The
":title:" directive option may be used to add extra information into the
title bar for the example. The ":annotated:" option can be used to write
arbitrary rST instead, with nested "::" blocks applying QMP formatting
where desired.
Other choices available are ".. code-block:: QMP" which will not create
an "Example:" box, or the short-form "::" code-block syntax which will
not apply QMP highlighting when used outside of the qmp-example
directive.
Why?
----
This patch has several benefits:
1. Example sections can now be written more arbitrarily, mixing
explanatory paragraphs and code blocks however desired.
2. Example sections can now use fully arbitrary rST.
3. All code blocks are now lexed and validated as QMP; increasing
usability of the docs and ensuring validity of example snippets.
(To some extent - This patch only gaurantees it lexes correctly, not
that it's valid under the JSON or QMP grammars. It will catch most
small mistakes, however.)
4. Each qmp-example can be titled or annotated independently without
bypassing the QMP lexer/validator.
(i.e. code blocks are now for *code* only, so we don't have to
sacrifice exposition for having lexically valid examples.)
NOTE: As with the "Notes" conversion (d461c279737), this patch (and the
three preceding) may change the rendering order for Examples in
the current generator. The forthcoming qapidoc rewrite will fix
this by always generating documentation in source order.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-ID: <20240717021312.606116-10-jsnow@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2024-07-17 05:13:11 +03:00
|
|
|
|
|
|
|
.. qmp-example::
|
|
|
|
:title: Ideal fast-food burger situation
|
|
|
|
|
|
|
|
-> "in"
|
|
|
|
<- "out"
|
|
|
|
|
|
|
|
Examples::
|
|
|
|
|
|
|
|
- Not a QMP code block
|
|
|
|
- Merely a preformatted code block literal
|
|
|
|
It isn't even an rST list.
|
2024-06-27 01:21:11 +03:00
|
|
|
- *verbatim*
|
|
|
|
- {braces}
|
qapi: remove "Example" doc section
Fully eliminate the "Example" sections in QAPI doc blocks now that they
have all been converted to arbitrary rST syntax using the
".. qmp-example::" directive. Update tests to match.
Migrating to the new syntax
---------------------------
The old "Example:" or "Examples:" section syntax is now caught as an
error, but "Example::" is stil permitted as explicit rST syntax for an
un-lexed, generic preformatted text block.
('Example' is not special in this case, any sentence that ends with "::"
will start an indented code block in rST.)
Arbitrary rST for Examples is now possible, but it's strongly
recommended that documentation authors use the ".. qmp-example::"
directive for consistent visual formatting in rendered HTML docs. The
":title:" directive option may be used to add extra information into the
title bar for the example. The ":annotated:" option can be used to write
arbitrary rST instead, with nested "::" blocks applying QMP formatting
where desired.
Other choices available are ".. code-block:: QMP" which will not create
an "Example:" box, or the short-form "::" code-block syntax which will
not apply QMP highlighting when used outside of the qmp-example
directive.
Why?
----
This patch has several benefits:
1. Example sections can now be written more arbitrarily, mixing
explanatory paragraphs and code blocks however desired.
2. Example sections can now use fully arbitrary rST.
3. All code blocks are now lexed and validated as QMP; increasing
usability of the docs and ensuring validity of example snippets.
(To some extent - This patch only gaurantees it lexes correctly, not
that it's valid under the JSON or QMP grammars. It will catch most
small mistakes, however.)
4. Each qmp-example can be titled or annotated independently without
bypassing the QMP lexer/validator.
(i.e. code blocks are now for *code* only, so we don't have to
sacrifice exposition for having lexically valid examples.)
NOTE: As with the "Notes" conversion (d461c279737), this patch (and the
three preceding) may change the rendering order for Examples in
the current generator. The forthcoming qapidoc rewrite will fix
this by always generating documentation in source order.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-ID: <20240717021312.606116-10-jsnow@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2024-07-17 05:13:11 +03:00
|
|
|
|
2024-06-27 01:21:19 +03:00
|
|
|
Note::
|
|
|
|
Ceci n'est pas une note
|
2017-03-20 16:11:54 +03:00
|
|
|
section=Since
|
|
|
|
2.10
|
|
|
|
doc symbol=cmd-boxed
|
|
|
|
body=
|
|
|
|
If you're bored enough to read this, go see a video of boxed cats
|
2019-10-24 14:02:22 +03:00
|
|
|
feature=cmd-feat1
|
|
|
|
a feature
|
|
|
|
feature=cmd-feat2
|
|
|
|
another feature
|
qapi: remove "Example" doc section
Fully eliminate the "Example" sections in QAPI doc blocks now that they
have all been converted to arbitrary rST syntax using the
".. qmp-example::" directive. Update tests to match.
Migrating to the new syntax
---------------------------
The old "Example:" or "Examples:" section syntax is now caught as an
error, but "Example::" is stil permitted as explicit rST syntax for an
un-lexed, generic preformatted text block.
('Example' is not special in this case, any sentence that ends with "::"
will start an indented code block in rST.)
Arbitrary rST for Examples is now possible, but it's strongly
recommended that documentation authors use the ".. qmp-example::"
directive for consistent visual formatting in rendered HTML docs. The
":title:" directive option may be used to add extra information into the
title bar for the example. The ":annotated:" option can be used to write
arbitrary rST instead, with nested "::" blocks applying QMP formatting
where desired.
Other choices available are ".. code-block:: QMP" which will not create
an "Example:" box, or the short-form "::" code-block syntax which will
not apply QMP highlighting when used outside of the qmp-example
directive.
Why?
----
This patch has several benefits:
1. Example sections can now be written more arbitrarily, mixing
explanatory paragraphs and code blocks however desired.
2. Example sections can now use fully arbitrary rST.
3. All code blocks are now lexed and validated as QMP; increasing
usability of the docs and ensuring validity of example snippets.
(To some extent - This patch only gaurantees it lexes correctly, not
that it's valid under the JSON or QMP grammars. It will catch most
small mistakes, however.)
4. Each qmp-example can be titled or annotated independently without
bypassing the QMP lexer/validator.
(i.e. code blocks are now for *code* only, so we don't have to
sacrifice exposition for having lexically valid examples.)
NOTE: As with the "Notes" conversion (d461c279737), this patch (and the
three preceding) may change the rendering order for Examples in
the current generator. The forthcoming qapidoc rewrite will fix
this by always generating documentation in source order.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-ID: <20240717021312.606116-10-jsnow@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2024-07-17 05:13:11 +03:00
|
|
|
section=None
|
|
|
|
.. qmp-example::
|
|
|
|
|
|
|
|
-> "this example"
|
2017-03-20 16:11:54 +03:00
|
|
|
|
qapi: remove "Example" doc section
Fully eliminate the "Example" sections in QAPI doc blocks now that they
have all been converted to arbitrary rST syntax using the
".. qmp-example::" directive. Update tests to match.
Migrating to the new syntax
---------------------------
The old "Example:" or "Examples:" section syntax is now caught as an
error, but "Example::" is stil permitted as explicit rST syntax for an
un-lexed, generic preformatted text block.
('Example' is not special in this case, any sentence that ends with "::"
will start an indented code block in rST.)
Arbitrary rST for Examples is now possible, but it's strongly
recommended that documentation authors use the ".. qmp-example::"
directive for consistent visual formatting in rendered HTML docs. The
":title:" directive option may be used to add extra information into the
title bar for the example. The ":annotated:" option can be used to write
arbitrary rST instead, with nested "::" blocks applying QMP formatting
where desired.
Other choices available are ".. code-block:: QMP" which will not create
an "Example:" box, or the short-form "::" code-block syntax which will
not apply QMP highlighting when used outside of the qmp-example
directive.
Why?
----
This patch has several benefits:
1. Example sections can now be written more arbitrarily, mixing
explanatory paragraphs and code blocks however desired.
2. Example sections can now use fully arbitrary rST.
3. All code blocks are now lexed and validated as QMP; increasing
usability of the docs and ensuring validity of example snippets.
(To some extent - This patch only gaurantees it lexes correctly, not
that it's valid under the JSON or QMP grammars. It will catch most
small mistakes, however.)
4. Each qmp-example can be titled or annotated independently without
bypassing the QMP lexer/validator.
(i.e. code blocks are now for *code* only, so we don't have to
sacrifice exposition for having lexically valid examples.)
NOTE: As with the "Notes" conversion (d461c279737), this patch (and the
three preceding) may change the rendering order for Examples in
the current generator. The forthcoming qapidoc rewrite will fix
this by always generating documentation in source order.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-ID: <20240717021312.606116-10-jsnow@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2024-07-17 05:13:11 +03:00
|
|
|
<- "has no title"
|
2021-03-23 12:40:10 +03:00
|
|
|
doc symbol=EVT_BOXED
|
2019-10-24 14:02:20 +03:00
|
|
|
body=
|
2019-10-24 14:02:24 +03:00
|
|
|
|
2020-03-17 14:54:37 +03:00
|
|
|
feature=feat3
|
|
|
|
a feature
|