diff --git a/docs/contributorfile.rst b/docs/contributorfile.rst
index 02ad8b3bf..8b5c610f4 100644
--- a/docs/contributorfile.rst
+++ b/docs/contributorfile.rst
@@ -1,8 +1,8 @@
 .. _contributorfile:
 
-==========================
-Contributing to `physiopy`
-==========================
+===============================
+How to contribute to `physiopy`
+===============================
 Welcome to the physiopy organisation! It’s great news you’re thinking about contributing!
 Working with many people from many different places is great, but sometimes this means the code can become messy due to the many different ways a contribution can be made. For this reason, we have set up some guidelines for contributions - to help you get along ASAP!
 Before you start you'll need to set up a free `GitHub <https://github.com/>`_ account and sign in. Here are some `instructions <https://help.github.com/articles/signing-up-for-a-new-github-account>`_.
@@ -36,6 +36,7 @@ Aims of physiopy
 ----------------
 physiopy is a **very** young project developed by a bunch of researchers from the two different sides of the Atlantic Ocean (for now).
 Our main goal is to help collect, analyse and share physiological data interfacing with (MRI) neuroimaging. We’re trying to do so by:
+
 1. Write packages to make a user-friendly pipeline to deal with physiological data.
 2. Organising a documentation containing tips and strategies on how to collect such data and use our packages.
 3. Write packages that take into account the use of such data in combination with neuroimaging (MRI) - by getting everything ready for that analysis.
@@ -175,9 +176,11 @@ When opening a pull request, assign it to at least one label.
 We encourage you to open a PR as soon as possible - even before you finish working on them. This is useful especially to you - so that you can receive comments and suggestions early on, rather than having to process a lot of comments in the final review step! 
 However, if it’s an incomplete PR, please open a **Draft PR**. That helps us process PRs by knowing which one to have a look first - and how picky to be when doing so.
 To be merged, PRs have to:
+
 1. Pass all the Travis CI tests.
 2. Have the necessary amount of approving reviews, even if you’re a long time contributor. You can ask one (or more) contributor to do that review, if you think they align more with the content of your PR. You need **one** review for documentation, tests, and small changes, and **two** reviews for bugs, refactoring and enhancements.
-3. Contain at least a unit test for your contribution, if the PR contains code (it would be better if it contains an integration or function test and all the breaking tests necessary), or an integration test if it contains documentation. If you’re not confident about writing tests, it is possible to refer to an issue that asks for the test to be written, or another (Draft) PR that contains the tests required.
+3. Contain at least a unit test for your contribution, if the PR contains code (it would be better if it contains an integration or function test and all the breaking tests necessary). If you’re not confident about writing tests, it is possible to refer to an issue that asks for the test to be written, or another (Draft) PR that contains the tests required.
+
 As we’re trying to maintain at least a 90% code coverance, you’re strongly encouraged to write all the necessary tests not to drop below the threshold. If our coverance becomes too low, you might be asked to add more tests and/or your PR might be rejected.
 
 .. _styling:
@@ -197,18 +200,19 @@ physiopy uses Continuous Integration (CI) to make life easier. In particular, we
 Travis CI uses `pytest <https://docs.pytest.org/en/latest/>`_ to run the tests. The great thing about it is that you can run it in advance on your local version of the code!
 We can measure the amount of code that is tested with [codecov]8https://docs.pytest.org/en/latest/), which is an indication of how reliable our packages are! We try to maintain a 90% code coverage, and for this reason, PR should contain tests!
 The four main type of tests we use are:
+
 1. Unit tests
-Unit tests check that a minimal piece of code is doing what it should be doing. Normally this means calling a function with some mock parameters and checking that the output is equal to the expected output. For example, to test a function that adds two given numbers together (1 and 3), we would call the function with those parameters, and check that the output is 4.
+    Unit tests check that a minimal piece of code is doing what it should be doing. Normally this means calling a function with some mock parameters and checking that the output is equal to the expected output. For example, to test a function that adds two given numbers together (1 and 3), we would call the function with those parameters, and check that the output is 4.
 2. Breaking tests
-Breaking tests are what you expect - they check that the program is breaking when it should. This means calling a function with parameters that are expected **not** to work, and check that it raises a proper error or warning.
+    Breaking tests are what you expect - they check that the program is breaking when it should. This means calling a function with parameters that are expected **not** to work, and check that it raises a proper error or warning.
 3. Integration tests
-Integration tests check that the code has an expected output, being blind to its content. This means that if the program should output a new file, the file exists - even if it’s empty. This type of tests are normally run on real data and call the program itself. For instance, documentation PRs should check that the documentation page is produced!
+    Integration tests check that the code has an expected output, being blind to its content. This means that if the program should output a new file, the file exists - even if it’s empty. This type of tests are normally run on real data and call the program itself. For instance, documentation PRs should check that the documentation page is produced!
 4. Functional tests
-If integration tests and unit tests could have babies, those would be functional tests. In practice, this kind of tests check that an output is produced, and *also* that it contains what it should contain. If a function should output a new file or an object, this test passes only if the file exists *and* it is like we expect it to be. They are run on real or mock data, and call the program itself or a function.
+    If integration tests and unit tests could have babies, those would be functional tests. In practice, this kind of tests check that an output is produced, and *also* that it contains what it should contain. If a function should output a new file or an object, this test passes only if the file exists *and* it is like we expect it to be. They are run on real or mock data, and call the program itself or a function.
 
 .. _recognising:
 
-Recognizing contributors
+Recognising contributors
 ------------------------
 We welcome and recognize `all contributions <https://allcontributors.org/docs/en/specification>`_ from documentation to testing to code development. You can see a list of current contributors in the README (kept up to date by the `all contributors bot <https://allcontributors.org/docs/en/bot/overview>`_).
 
diff --git a/docs/heuristic.rst b/docs/heuristic.rst
index ad22d74b7..cf608aea9 100644
--- a/docs/heuristic.rst
+++ b/docs/heuristic.rst
@@ -10,73 +10,19 @@ Anatomy of a heuristic file
 ---------------------------
 
 Let's have a look under the hood of the heuristic files used in the `tutorial <howto.html>`_.
-It's the file ``heur_tutorial.py`` in ``phys2bids/phy2bids/heuristics/``::
-
-    import fnmatch
-
-
-    def heur(physinfo, name, task='', acq='', direct='', rec='', run=''):
-        # ############################## #
-        # ##       Modify here!       ## #
-        # ##                          ## #
-        # ##  Possible variables are: ## #
-        # ##    -task (required)      ## #
-        # ##    -run                  ## #
-        # ##    -rec                  ## #
-        # ##    -acq                  ## #
-        # ##    -direct               ## #
-        # ##                          ## #
-        # ##                          ## #
-        # ##    See example below     ## #
-        # ############################## #
-
-        if fnmatch.fnmatchcase(physinfo, '*tutorial*'):
-            task = 'test'
-            run = '00'
-            rec = 'labchart'
-        elif physinfo == 'Example':
-            task = 'rest'
-            run = '01'
-            acq = 'resp'
-            # ############################## #
-            # ## Don't modify below this! ## #
-            # ############################## #
-        else:
-            # #!# Transform sys.exit in debug warnings or raiseexceptions!
-            # #!# Make all of the above a dictionary
-            raise Warning(f'The heuristic {__file__} could not deal with {physinfo}')
-
-        if not task:
-            raise KeyError(f'No "task" attribute found')
-
-        name = name + '_task-' + task
-
-        # filename spec: sub-<label>[_ses-<label>]_task-<label>[_acq-<label>] ...
-        #                ... [_ce-<label>][_dir-<label>][_rec-<label>] ...
-        #                ... [_run-<index>][_recording-<label>]_physio
-        if acq:
-            name = name + '_acq-' + acq
-
-        if direct:
-            name = name + '_dir-' + direct
-
-        if rec:
-            name = name + '_rec-' + rec
-
-        if run:
-            name = name + '_run-' + run
-
-        return name
+It's the file ``heur_tutorial.py`` in ``phys2bids/phy2bids/heuristics/``:
+
+.. literalinclude:: ../phys2bids/heuristics/heur_tutorial.py
+   :linenos:
 
 We can split this file into three parts: the initialisation, the dictionaries, and the functional code.
 
 Initialisation
 ^^^^^^^^^^^^^^
-::
-    import fnmatch
-
 
-    def heur(physinfo, name, task='', acq='', direct='', rec='', run=''):
+.. literalinclude:: ../phys2bids/heuristics/heur_tutorial.py
+   :linenos:
+   :lines: 1-4
 
 It's important **not to modify this part of the file**. Instead, you can copy and paste it into your own heuristic file.
 
@@ -90,32 +36,12 @@ The scripts imports ``fnmatch``, a nice python module that lets you use bash-lik
 
 Dictionaries
 ^^^^^^^^^^^^
-::
-    # ############################## #
-    # ##       Modify here!       ## #
-    # ##                          ## #
-    # ##  Possible variables are: ## #
-    # ##    -task (required)      ## #
-    # ##    -run                  ## #
-    # ##    -rec                  ## #
-    # ##    -acq                  ## #
-    # ##    -direct               ## #
-    # ##                          ## #
-    # ##                          ## #
-    # ##    See example below     ## #
-    # ############################## #
-
-    if fnmatch.fnmatchcase(physinfo, '*tutorial*'):
-        task = 'test'
-        run = '00'
-        rec = 'labchart'
-    elif physinfo == 'Example':
-        task = 'rest'
-        run = '01'
-        acq = 'resp'
-        # ############################## #
-        # ## Don't modify below this! ## #
-        # ############################## #
+
+.. literalinclude:: ../phys2bids/heuristics/heur_tutorial.py
+   :linenos:
+   :lines: 5-29
+   :lineno-start: 5
+   :dedent: 4
 
 This is the core of the function, and the part that should be adapted to process your files. In practice, it's the beginning of a |statement|_.
 | You need an ``if`` or ``elif`` statement for each file that you want to process, that will test if the ``physinfo`` is similar to a string (first case) or exactly matches a string (second case). The content of the statement is a set of `variable initialisations as a string <https://www.w3schools.com/python/python_strings.asp>`_.
@@ -127,7 +53,7 @@ This is the core of the function, and the part that should be adapted to process
 - ``acq`` is the optional entity for the `set of acquisition parameters <https://bids-specification.readthedocs.io/en/stable/04-modality-specific-files/01-magnetic-resonance-imaging-data.html#the-acq-entity>`_.
 - ``direct`` is the equivalent of the ``dic`` entity, an optional entity for the phase encoding direction (see `here <https://bids-specification.readthedocs.io/en/stable/04-modality-specific-files/01-magnetic-resonance-imaging-data.html#task-including-resting-state-imaging-data>`_).
 
-Note that one mandatory BIDs entity is missing: the **``sub`` entity**, corresponding to the subject label. This is because it has to be specified while calling ``phys2bids``, as it's explained in the `tutorial <howto.html#generating-outputs-in-bids-format>`_. The **session entity** can be specified in the same way. Moreover, if you have a **multifrequency file** there will be another entity, ``recording`` automatically added to those specified here, and containing the sample frequency of the different outputs.
+Note that one mandatory BIDs entity is missing: the **``sub`` entity**, correspondent to the subject label. This is because it has to be specified while calling ``phys2bids``, as it's explained in the tutorial section `"generating-outputs-in-bids-format" <howto.html#generating-outputs-in-bids-format>`_. The **session entity** can be specified in the same way. Moreover, if you have a **multifrequency file** there will be another entity, ``recording`` automatically added to those specified here, and containing the sample frequency of the different outputs.
 
 Let's try to read the first statement in the example:
 
@@ -137,40 +63,16 @@ Note that we used only a subset of possible entities.
 
 .. _statement: https://www.w3resource.com/python/python-if-else-statements.php
 
-.. |covenant| replace:: ``if .. elif .. else`` statement.
+.. |statement| replace:: ``if .. elif .. else`` statement.
 
 Functional code
 ^^^^^^^^^^^^^^^
-::
-    # ############################## #
-    # ## Don't modify below this! ## #
-    # ############################## #
-    else:
-        # #!# Transform sys.exit in debug warnings or raiseexceptions!
-        # #!# Make all of the above a dictionary
-        raise Warning(f'The heuristic {__file__} could not deal with {physinfo}')
-
-    if not task:
-        raise KeyError(f'No "task" attribute found')
-
-    name = name + '_task-' + task
-
-    # filename spec: sub-<label>[_ses-<label>]_task-<label>[_acq-<label>] ...
-    #                ... [_ce-<label>][_dir-<label>][_rec-<label>] ...
-    #                ... [_run-<index>][_recording-<label>]_physio
-    if acq:
-        name = name + '_acq-' + acq
 
-    if direct:
-        name = name + '_dir-' + direct
-
-    if rec:
-        name = name + '_rec-' + rec
-
-    if run:
-        name = name + '_run-' + run
-
-    return name
+.. literalinclude:: ../phys2bids/heuristics/heur_tutorial.py
+   :linenos:
+   :lines: 27-
+   :lineno-start: 27
+   :dedent: 4
 
 This part contains some code that composes the heuristic function output.
 It's important **not to modify this part of the file**. Instead, you can copy paste it in your own heuristic file.
@@ -179,9 +81,12 @@ There's a warning that will raise if the file wasn't able to process the input f
 Using the heuristic file
 ------------------------
 
-Once you modified your heuristic file or created a new one, you can save it anywhere you want, as a python script (``somename.py``). Check that the file is **executable**! Then, you will have to call ``phys2bids`` using the ``-heur``, the ``-sub``, and optionally the ``-ses``, arguments::
+Once you modified your heuristic file or created a new one, you can save it anywhere you want, as a python script (``somename.py``). Check that the file is **executable**! Then, you will have to call ``phys2bids`` using the ``-heur``, the ``-sub``, and optionally the ``-ses``, arguments:
+
+.. code-block:: shell
 
     phys2bids -in tutorial_file.txt -chtrig 1 -outdir /home/arthurdent/physio_bids -ntp 158 -tr 1.2 -thr 0.735 -heur /home/arthurdent/git/phys2bids/phys2bids/heuristics/heur_tutorial.py -sub 006 -ses 01
 
 Remember to **specify the full path** to the heuristic file. A copy of the heuristic file will be saved in the site folder.
-You can find more information in the `tutorial <howto.html#generating-outputs-in-bids-format>`_.
+
+You can find more information in the `relevant tutorial section <howto.html#generating-outputs-in-bids-format>`_.
diff --git a/docs/howto.rst b/docs/howto.rst
index 067d30d7e..fe652b219 100644
--- a/docs/howto.rst
+++ b/docs/howto.rst
@@ -17,30 +17,20 @@ Setup
 
 In order to follow the tutorial, you need a very quick setup: download or clone the `github repository <https://github.com/physiopy/phys2bids>`_ and install either the latest stable or development release as described `here <installation.html#install-with-pip>`_.
 
-**Note**: for the tutorial, we will assume the repository was downloaded in ``/home/arthurdent/git``. Let's get there right now::
+**Note**: for the tutorial, we will assume the repository was downloaded in ``/home/arthurdent/git``. Let's get there right now:
+
+.. code-block:: shell
 
     cd /home/arthurdent/git/
 
 What is in the tutorial text file?
 ##################################
 
-The file can be found in ``phys2bids/phys2bids/tests/data/tutorial_file.txt``. This file has header information (first 9 lines) which phys2bids will use to process this file, alongside information directly inputted by the user. Following this header information, the data in the file is stored in a column format. In this example, we have time (column 1), MRI trigger pulse (column 2), CO2 (column 3), O2 (column 4) and pulse (column 5). Each column was sampled at 1000Hz (Interval = 0.001 s). ::
-
-    Interval=	0.001 s
-    ExcelDateTime=	4.3749464322749809e+04	10/11/19 11:08:37.485584
-    TimeFormat=	StartOfBlock
-    DateFormat=
-    ChannelTitle=	Trigger	CO2	O2	Pulse
-    Range=	2.000 V	50.0 mmHg	180.0 mmHg	10.000 V
-    UnitName=	*	mmHg	mmHg	*
-    TopValue=	*	56.44	180.80	*
-    BottomValue=	*	-0.09	-0.96	*
-    432.000 0.5810 0.7649 157.8775 0.0163
-    432.001 0.5809 0.7621 157.8775 0.0213
-    432.002 0.5810 0.7621 157.8295 0.0313
-    432.003 0.5810 0.7621 157.8295 0.0319
-    432.004 0.5810 0.7621 157.9255 0.0275
-    432.005 0.5809 0.7595 157.8775 0.0288
+The file can be found in ``phys2bids/phys2bids/tests/data/tutorial_file.txt``. This file has header information (first 9 lines) which phys2bids will use to process this file, alongside information directly inputted by the user. Following this header information, the data in the file is stored in a column format. In this example, we have time (column 1), MRI trigger pulse (column 2), CO2 (column 3), O2 (column 4) and pulse (column 5). Each column was sampled at 1000Hz (Interval = 0.001 s).
+
+.. literalinclude:: ../phys2bids/tests/data/tutorial_file.txt
+   :linenos:
+   :lines: 1-15
 
 **Note**: time is not a "real" channel recorded by LabChart or AcqKnowledge. For this reason, ``phys2bids`` treats it as a hidden channel, always in position 0. Channel 1 will be the first channel recorded in either software.
 
@@ -49,17 +39,23 @@ Using the -info option
 
 First, we can see what information ``phys2bids`` reads from the file, and make sure this is correct before processing the file.
 
-The simplest way of calling ``phys2bids`` is moving to the folder containing the physiological file and typing::
+The simplest way of calling ``phys2bids`` is moving to the folder containing the physiological file and typing:
+
+.. code-block:: shell
 
     cd phys2bids/phys2bids/tests/data/
     phys2bids -in tutorial_file
 
 ``pys2bids`` will try to get the extension for you. 
-However, we’ll use one more argument to have a sneak peak into the content of the file::
+However, we’ll use one more argument to have a sneak peak into the content of the file:
+
+.. code-block:: shell
 
     phys2bids -in tutorial_file.txt -info
 
-This ``-info`` argument means ``phy2bids`` does not process the file, but only outputs information it reads from the file, by printing to the terminal and outputting a png plot of the data in the current directory::
+This ``-info`` argument means ``phy2bids`` does not process the file, but only outputs information it reads from the file, by printing to the terminal and outputting a png plot of the data in the current directory:
+
+.. code-block:: shell
 
     INFO:phys2bids.phys2bids:Currently running phys2bids version v1.3.0-beta+149.ge4a3c87
     INFO:phys2bids.phys2bids:Input file is tutorial_file.txt
@@ -93,11 +89,15 @@ Specifying paths and names
 
 Now we'll call ``phys2bids`` without the ``-info`` option. We'll use the same inputs as above, as well as adding ``-indir``, ``-outdir``, and ``-chplot``. If you use ``-indir`` you can specify a path to your input file i.e. it does not have to be in the current directory, as is the default. Using the ``-chplot`` argument allows you to specify the name (and full path) for the png channel plot. The ``-indir`` and ``-chplot`` arguments can be used alongside the ``-info`` argument. When calling ``phys2bids`` without the ``-info`` argument, it will generate files; if you use the ``-outdir`` argument this is where ``phys2bids`` will save these files - if the folder doesn't exist, it will be created.
 
-Unless specified with ``-chsel`` ``phys2bids`` will process and output all channels. Unless specified with ``-chnames`` ``phys2bids`` will read the channel names from the header information in the file.  ::
+Unless specified with ``-chsel`` ``phys2bids`` will process and output all channels. Unless specified with ``-chnames`` ``phys2bids`` will read the channel names from the header information in the file.
+
+.. code-block:: shell
 
     phys2bids -in tutorial_file.txt -indir /home/arthurdent/git/phys2bids/phys2bids/tests/data/ -chtrig 1 -outdir /home/arthurdent/physio
 
-This is outputted to the terminal::
+This is outputted to the terminal:
+
+.. code-block:: shell
 
     INFO:phys2bids.phys2bids:Currently running phys2bids version v1.3.0-beta+149.ge4a3c87.dirty
     INFO:phys2bids.phys2bids:Input file is tutorial_file.txt
@@ -154,11 +154,15 @@ If you recorded the trigger of your **(f)MRI**, ``phys2bids`` can use it to dete
 First, we need to tell ``phys2bids`` where our trigger channel is, and we can use the argument ``-chtrig``. ``-chtrig`` has a default of 0, which means that if there is no input given ``phys2bids`` will assume the trigger information is in the hidden time channel.
 For the text file used in this example, the trigger information is the second column of the raw file; the first recorded channel.
 
-The last command line output said "Counting trigger points" and "The necessary options to find the amount of timepoints were not provided", so we need to give ``phys2bids`` some more information for it to correctly read the trigger information in the data. In this tutorial file, there are 158 triggers and the TR is 1.2 seconds. Using these arguments, we can call ``phys2bids`` again::
+The last command line output said "Counting trigger points" and "The necessary options to find the amount of timepoints were not provided", so we need to give ``phys2bids`` some more information for it to correctly read the trigger information in the data. In this tutorial file, there are 158 triggers and the TR is 1.2 seconds. Using these arguments, we can call ``phys2bids`` again:
+
+.. code-block:: shell
 
     phys2bids -in tutorial_file -chtrig 1 -outdir /home/arthurdent/physio -ntp 158 -tr 1.2
 
-The output still warns us about something::
+The output still warns us about something:
+
+.. code-block:: shell
 
     WARNING:phys2bids.physio_obj:Found 158 timepoints less than expected!
     WARNING:phys2bids.physio_obj:Correcting time offset, assuming missing timepoints are at the beginning (try again with a more liberal thr)
@@ -166,7 +170,9 @@ The output still warns us about something::
 How come?!? We know there are exactly 158 timepoints![#]_ In order to find the triggers, ``phys2bids`` gets the first derivative of the trigger channel, and uses a threshold (default 2.5) to get the peaks of the derivative, corresponding to the trigger event. If the threshold is too strict or is too liberal for the recorded trigger, it won't get all the trigger points.
 | ``phys2bids`` was created to deal with little sampling errors - such as distracted researchers that started sampling a bit too late than expected. For this reason, if it finds less timepoints than the amount specified, it will assume that the error was caused by a *distracted researcher*. 
 
-Therefore, we need to change the ``-thr`` input until ``phys2bids`` finds the correct number of timepoints. Looking at the tutorial_file_trigger_time.png file can help determine what threshold is more appropriate. For this tutorial file, a threshold of 0.735 finds the right number of time points. ::
+Therefore, we need to change the ``-thr`` input until ``phys2bids`` finds the correct number of timepoints. Looking at the tutorial_file_trigger_time.png file can help determine what threshold is more appropriate. For this tutorial file, a threshold of 0.735 finds the right number of time points.
+
+.. code-block:: shell
 
     phys2bids -in tutorial_file -chtrig 1 -outdir /home/arthurdent/physio -ntp 158 -tr 1.2 -thr 0.735
 
@@ -204,7 +210,6 @@ Therefore, we need to change the ``-thr`` input until ``phys2bids`` finds the co
     Tip: Time 0 is the time of first trigger
     ------------------------------------------------
 
-
 .. image:: _static/tutorial_file_trigger_time.png
    :alt: tutorial_file_trigger_time
    :align: center
@@ -224,37 +229,25 @@ Generating outputs in BIDs format
 
 Alright, now the really interesting part! This section will explain how to use the ``-heur``, ``-sub``, and ``-ses`` arguments, to save the files in BIDs format. After all, that's probably why you're here.
 
-``phys2bids`` uses heuristic rules *à la* `heudiconv <https://github.com/nipy/heudiconv>`_. At the moment, it can only use the name of the file to understand what should be done with it but we're working on making it *smarter*. There is a complete heuristic file for the tutorial, in the ``heuristics`` folder. Inside it looks more or less like this::
-
-    def heur(physinfo, name, task='', acq='', direct='', rec='', run=''):
-    # ############################## #
-    # ##       Modify here!       ## #
-    # ##                          ## #
-    # ##  Possible variables are: ## #
-    # ##    -task (required)      ## #
-    # ##    -run                  ## #
-    # ##    -rec                  ## #
-    # ##    -acq                  ## #
-    # ##    -direct               ## #
-    # ##                          ## #
-    # ##                          ## #
-    # ##    See example below     ## #
-    # ############################## #
-
-    if fnmatch.fnmatchcase(physinfo, '*tutorial*'):
-        task = 'test'
-        run = '00'
-        rec = 'labchart'
-    [...]
+``phys2bids`` uses heuristic rules *à la* `heudiconv <https://github.com/nipy/heudiconv>`_. At the moment, it can only use the name of the file to understand what should be done with it but we're working on making it *smarter*. There is a complete heuristic file for the tutorial, in the ``heuristics`` folder. Inside it looks more or less like this:
+
+.. literalinclude:: ../phys2bids/heuristics/heur_tutorial.py
+   :linenos:
+   :lines: 4-22
+   :lineno-start: 4
 
 The heuristic file has to be written accordingly, with a set of rules that could work for all the files in your dataset. You can learn more about it if you check the `guide on how to set it up <heuristic.html>`_.
 In this case, our heuristic file looks for a file that contains the name ``tutorial``. It corresponds to the task ``test`` and run ``00``. Note that **only the task is required**, all the other fields are optional - look them up in the BIDs documentation and see if you need them.
 
-As there might not be a link between the physiological file and the subject (and session) that it relates to, ``phys2bids`` requires such information to be given from the user. In order for the *BIDsification* to happen, ``phys2bids`` needs the **full path** to the heuristic file, as well as the subject label. The session label is optional. The ``-outdir`` option will become the root folder for your BIDs files - i.e. your *site folder* ::
+As there might not be a link between the physiological file and the subject (and session) that it relates to, ``phys2bids`` requires such information to be given from the user. In order for the *BIDsification* to happen, ``phys2bids`` needs the **full path** to the heuristic file, as well as the subject label. The session label is optional. The ``-outdir`` option will become the root folder for your BIDs files - i.e. your *site folder*:
+
+.. code-block:: shell
 
     phys2bids -in tutorial_file.txt -chtrig 1 -outdir /home/arthurdent/physio_bids -ntp 158 -tr 1.2 -thr 0.735 -heur /home/arthurdent/git/phys2bids/phys2bids/heuristics/heur_tutorial.py -sub 006 -ses 01
 
-The terminal output is as follows::
+The terminal output is as follows:
+
+.. code-block:: shell
 
     INFO:phys2bids.phys2bids:Currently running phys2bids version v1.3.0-beta+152.g1f98d16.dirty
     INFO:phys2bids.phys2bids:Input file is tutorial_file.txt
@@ -278,7 +271,7 @@ The terminal output is as follows::
     INFO:phys2bids.physio_obj:Found just the right amount of timepoints!
     INFO:phys2bids.phys2bids:Plot trigger
     INFO:phys2bids.phys2bids:Preparing 1 output files.
-    INFO:phys2bids.phys2bids:Preparing BIDS output using /home/nemo/Scrivania/gitlab/phys2bids/phys2bids/heuristics/heur_tutorial.py
+    INFO:phys2bids.phys2bids:Preparing BIDS output using /home/arthurdent/git/phys2bids/phys2bids/heuristics/heur_tutorial.py
     INFO:phys2bids.phys2bids:Exporting files for freq 1000.0
     INFO:phys2bids.phys2bids:
     ------------------------------------------------
@@ -292,7 +285,9 @@ The terminal output is as follows::
     ------------------------------------------------
 
 It seems very similar to the last call - let's check the output folder.
-It now contains the logger file, the trigger_time plot, and a folder for the specified subject, that (optionally) contains a folder for the session, containing a folder for the functional data, containing the log file and the required BIDs files with the right name! ::
+It now contains the logger file, the trigger_time plot, and a folder for the specified subject, that (optionally) contains a folder for the session, containing a folder for the functional data, containing the log file and the required BIDs files with the right name!
+
+.. code-block:: none
 
     - /home/arthurdent/physio_bids /
         - tutorial_file_sub-006_sub-01_trigger_time.png