docs: Use code-blocks when non-python code

The default block-comment uses python or no-highlight. Let's manually
set the diff/yaml/... code-blocks whenever it could be useful to
increase readability of our documentation.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

docs/source/Configuration.rst

@@ -9,7 +9,9 @@ and that's why a configuration system is in place to help with those cases
 The Avocado config file format is based on the (informal)
 `INI file 'specification' <http://en.wikipedia.org/wiki/INI_file>`__, that is implemented by
 Python's  :mod:`ConfigParser`. The format is simple and straightforward, composed by `sections`,
-that contain a number of `keys` and `values`. Take for example a basic Avocado config file::
+that contain a number of `keys` and `values`. Take for example a basic Avocado config file:
+
+.. code-block:: ini
 
     [datadir.paths]
     base_dir = ~/avocado
@@ -50,7 +52,9 @@ Plugin config files
 Plugins can also be configured by config files. In order to not disturb the main Avocado config file, those plugins,
 if they wish so, may install additional config files to ``/etc/avocado/conf.d/[pluginname].conf``, that will be parsed
 after the system wide config file. Users can override those values as well at the local config file level.
-Considering the config for the hypothethical plugin ``salad``::
+Considering the config for the hypothethical plugin ``salad``:
+
+.. code-block:: ini
 
     [salad.core]
     base = ceasar

docs/source/Diff.rst

@@ -5,7 +5,9 @@ Job Diff
 ========
 
 Avocado Diff plugin allows users to easily compare several aspects of
-two given jobs. The basic usage is::
+two given jobs. The basic usage is:
+
+.. code-block:: diff
 
     $ avocado diff 7025aaba 384b949c
     --- 7025aaba9c2ab8b4bba2e33b64db3824810bb5df
@@ -40,7 +42,9 @@ can also enable/disable those sections with ``--diff-filter``. Please see
 ``avocado diff --help`` for more information.
 
 Jobs can be identified by the Job ID, by the results directory or by the
-key ``latest``. Example::
+key ``latest``. Example:
+
+.. code-block:: diff
 
     $ avocado diff ~/avocado/job-results/job-2016-08-03T15.56-4b3cb5b/ latest
     --- 4b3cb5bbbb2435c91c7b557eebc09997d4a0f544

docs/source/MaintenanceGuide.rst

@@ -12,7 +12,9 @@ Bump the version number
 =======================
 
 Go through the avocado code base and update the release number. At the time
-of this writing, the diff looked like this::
+of this writing, the diff looked like this:
+
+.. code-block:: diff
 
     diff --git a/avocado.spec b/avocado.spec
     index eb910e8..21313ca 100644

docs/source/Mux.rst

@@ -102,7 +102,9 @@ of parameters.
 
 Let's start with an example (line numbers at the first columns are for
 documentation purposes only, they are not part of the multiplex file
-format)::
+format):
+
+.. code-block:: yaml
 
      1  hw:
      2      cpu: !mux
@@ -181,7 +183,9 @@ Each node can define key/value pairs (lines 4,6,8,11,...). Additionally
 each children node inherits values of it's parent and the result is called
 node ``environment``.
 
-Given the node structure bellow::
+Given the node structure bellow:
+
+.. code-block:: yaml
 
     devtools:
         compiler: 'cc'
@@ -217,7 +221,9 @@ Variants
 --------
 
 In the end all leaves are gathered and turned into parameters, more specifically into
-``AvocadoParams``::
+``AvocadoParams``:
+
+.. code-block:: yaml
 
     setup:
         graphic:
@@ -235,7 +241,9 @@ by path. But the most powerful multiplexer feature is that it can generate
 multiple variants. To do that you need to tag a node whose children are
 ment to be multiplexed. Effectively it returns only leaves of one child at the
 time.In order to generate all possible variants multiplexer creates cartesian
-product of all of these variants::
+product of all of these variants:
+
+.. code-block:: yaml
 
     cpu: !mux
         intel:
@@ -253,7 +261,9 @@ Produces 6 variants::
     /cpu/arm, /fmt/raw
 
 The !mux evaluation is recursive so one variant can expand to multiple
-ones::
+ones:
+
+.. code-block:: yaml
 
     fmt: !mux
         qcow: !mux
@@ -291,7 +301,9 @@ be overridden by ``--mux-path``, which accepts multiple arguments. What it does
 it splits leaves by the provided paths. Each query goes one by one through
 those sub-trees and first one to hit the match returns the result. It might not
 solve all problems, but it can help to combine existing YAML files with your
-ones::
+ones:
+
+.. code-block:: yaml
 
     qa:         # large and complex read-only file, content injected into /qa
         tests:
@@ -363,7 +375,9 @@ Multiple files
 
 You can provide multiple files. In such scenario final tree is a combination
 of the provided files where later nodes with the same name override values of
-the preceding corresponding node. New nodes are appended as new children::
+the preceding corresponding node. New nodes are appended as new children:
+
+.. code-block:: yaml
 
     file-1.yaml:
         debug:
@@ -377,7 +391,9 @@ the preceding corresponding node. New nodes are appended as new children::
         fast:
             CFLAGS: '-Ofast'
 
-results in::
+results in:
+
+.. code-block:: yaml
 
     debug:
         CFLAGS: '-O0 -g'
@@ -387,7 +403,9 @@ results in::
         CFLAGS: '-Ofast'    # appended
 
 It's also possible to include existing file into another a given node in another
-file. This is done by the `!include : $path` directive::
+file. This is done by the `!include : $path` directive:
+
+.. code-block:: yaml
 
     os:
         fedora:
@@ -415,7 +433,9 @@ name and the parsing fails.
 !include
 --------
 
-Includes other file and injects it into the node it's specified in::
+Includes other file and injects it into the node it's specified in:
+
+.. code-block:: yaml
 
     my_other_file:
         !include : other.yaml
@@ -428,7 +448,9 @@ Relative paths start from the original file's directory.
 !using
 ------
 
-Prepends path to the node it's defined in::
+Prepends path to the node it's defined in:
+
+.. code-block:: yaml
 
     !using : /foo
     bar:
@@ -441,7 +463,9 @@ Prepends path to the node it's defined in::
 ------------
 
 Removes node if it existed during the merge. It can be used to extend
-incompatible YAML files::
+incompatible YAML files:
+
+.. code-block:: yaml
 
     os:
         fedora:

docs/source/WritingTests.rst

@@ -94,7 +94,9 @@ Each test has a set of parameters that can be accessed through
 ``self.params.get($name, $path=None, $default=None)``.
 Avocado finds and populates ``self.params`` with all parameters you define on
 a Multiplex Config file (see :doc:`Mux`). As an example, consider
-the following multiplex file for sleeptest::
+the following multiplex file for sleeptest:
+
+.. code-block:: yaml
 
     sleeptest:
         type: "builtin"