mirror of
https://github.com/Motorhead1991/qemu.git
synced 2025-07-27 04:13:53 -06:00
docs/devel/qapi-code-gen: Tidy up whitespace
Consistently use two spaces to separate sentences. Put "::" on a line of its own when it's preceded by whitespace. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20250404121413.1743790-2-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
This commit is contained in:
parent
dfaecc04c4
commit
23d017ca84
1 changed files with 14 additions and 12 deletions
|
@ -763,8 +763,8 @@ Names beginning with ``x-`` used to signify "experimental". This
|
||||||
convention has been replaced by special feature "unstable".
|
convention has been replaced by special feature "unstable".
|
||||||
|
|
||||||
Pragmas ``command-name-exceptions`` and ``member-name-exceptions`` let
|
Pragmas ``command-name-exceptions`` and ``member-name-exceptions`` let
|
||||||
you violate naming rules. Use for new code is strongly discouraged. See
|
you violate naming rules. Use for new code is strongly discouraged.
|
||||||
`Pragma directives`_ for details.
|
See `Pragma directives`_ for details.
|
||||||
|
|
||||||
|
|
||||||
Downstream extensions
|
Downstream extensions
|
||||||
|
@ -1013,7 +1013,7 @@ like this::
|
||||||
document the success and the error response, respectively.
|
document the success and the error response, respectively.
|
||||||
|
|
||||||
"Errors" sections should be formatted as an rST list, each entry
|
"Errors" sections should be formatted as an rST list, each entry
|
||||||
detailing a relevant error condition. For example::
|
detailing a relevant error condition. For example::
|
||||||
|
|
||||||
# Errors:
|
# Errors:
|
||||||
# - If @device does not exist, DeviceNotFound
|
# - If @device does not exist, DeviceNotFound
|
||||||
|
@ -1026,13 +1026,13 @@ definition.
|
||||||
QMP). In other sections, the text is formatted, and rST markup can be
|
QMP). In other sections, the text is formatted, and rST markup can be
|
||||||
used.
|
used.
|
||||||
|
|
||||||
QMP Examples can be added by using the ``.. qmp-example::``
|
QMP Examples can be added by using the ``.. qmp-example::`` directive.
|
||||||
directive. In its simplest form, this can be used to contain a single
|
In its simplest form, this can be used to contain a single QMP code
|
||||||
QMP code block which accepts standard JSON syntax with additional server
|
block which accepts standard JSON syntax with additional server
|
||||||
directionality indicators (``->`` and ``<-``), and elisions (``...``).
|
directionality indicators (``->`` and ``<-``), and elisions (``...``).
|
||||||
|
|
||||||
Optionally, a plaintext title may be provided by using the ``:title:``
|
Optionally, a plaintext title may be provided by using the ``:title:``
|
||||||
directive option. If the title is omitted, the example title will
|
directive option. If the title is omitted, the example title will
|
||||||
default to "Example:".
|
default to "Example:".
|
||||||
|
|
||||||
A simple QMP example::
|
A simple QMP example::
|
||||||
|
@ -1043,10 +1043,10 @@ A simple QMP example::
|
||||||
# -> { "execute": "query-block" }
|
# -> { "execute": "query-block" }
|
||||||
# <- { ... }
|
# <- { ... }
|
||||||
|
|
||||||
More complex or multi-step examples where exposition is needed before or
|
More complex or multi-step examples where exposition is needed before
|
||||||
between QMP code blocks can be created by using the ``:annotated:``
|
or between QMP code blocks can be created by using the ``:annotated:``
|
||||||
directive option. When using this option, nested QMP code blocks must be
|
directive option. When using this option, nested QMP code blocks must
|
||||||
entered explicitly with rST's ``::`` syntax.
|
be entered explicitly with rST's ``::`` syntax.
|
||||||
|
|
||||||
Highlighting in non-QMP languages can be accomplished by using the
|
Highlighting in non-QMP languages can be accomplished by using the
|
||||||
``.. code-block:: lang`` directive, and non-highlighted text can be
|
``.. code-block:: lang`` directive, and non-highlighted text can be
|
||||||
|
@ -1466,7 +1466,9 @@ As an example, we'll use the following schema, which describes a
|
||||||
single complex user-defined type, along with command which takes a
|
single complex user-defined type, along with command which takes a
|
||||||
list of that type as a parameter, and returns a single element of that
|
list of that type as a parameter, and returns a single element of that
|
||||||
type. The user is responsible for writing the implementation of
|
type. The user is responsible for writing the implementation of
|
||||||
qmp_my_command(); everything else is produced by the generator. ::
|
qmp_my_command(); everything else is produced by the generator.
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
$ cat example-schema.json
|
$ cat example-schema.json
|
||||||
{ 'struct': 'UserDefOne',
|
{ 'struct': 'UserDefOne',
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue