Inline Python code ends up at different position

[s-martin]

Environment

• Pydoc-Markdown Version: v4.8.2
• Python Version: v3.10
• Operating System: Ubuntu (WSL image)

Describe the bug

When I use code examples following markdown syntax within the docstring the generated markdown file puts the code at the end of the chapter.

I use this docstring:

The code sample at the first example is formatted using regular markdown syntax (```python

"""
A plugin package with some special functionality

Plugins packages are python packages that are dynamically loaded. From these packages only a subset of objects is exposed
through the plugs.call interface. The python packages can use decorators or dynamic function call to register (callable)
objects.

The python package name may be different from the name the package is registered under in plugs. This allows to load different
python packages for a specific feature based on a configuration file. Note: Python package are still loaded as regular
python packages and can be accessed by normal means

If you want to provide additional functionality to the same feature (probably even for run-time switching)
you can implement a Factory Pattern using this package. Take a look at volume.py as an example.

**Example:** Decorate a function for auto-registering under it's own name:

```python
    import jukebox.plugs as plugs
    @plugs.register
    def func1(param):
        pass
```

**Example:** Decorate a function for auto-registering under a new name::

    @plugs.register(name='better_name')
    def func2(param):
        pass

**Example:** Register a function during run-time under it's own name::

    def func3(param):
        pass
    plugs.register(func3)

**Example:** Register a function during run-time under a new name::

    def func4(param):
        pass
    plugs.register(func4, name='other_name', package='other_package')

**Example:** Decorate a class for auto registering during initialization,
including all methods (see _register_class for more info)::

    @plugs.register(auto_tag=True)
    class MyClass1:
        pass

**Example:** Register a class instance, from which only report is a callable method through the plugs interface::

    class MyClass2:
        @plugs.tag
        def report(self):
            pass
    myinst2 = MyClass2()
    plugin.register(myinst2, name='myinst2')

Naming convention:

package
    1. Either a python package
    2. or a plugin package (which is the python package but probably loaded under a different name inside plugs)

plugin
    1. An object from the package that can be accessed through the plugs call function (i.e. a function or a class instance)
    2. The string name to above object

name
    The string name of the plugin object for registration

method
    1. In case the object is a class instance a bound method to call from the class instance
    2. The string name to above object

"""

This results in the following markdown code:

The code sample from above is missing at Example, but shown at the very end.

<a id="jukebox.plugs"></a>

# jukebox.plugs

A plugin package with some special functionality

Plugins packages are python packages that are dynamically loaded. From these packages only a subset of objects is exposed
through the plugs.call interface. The python packages can use decorators or dynamic function call to register (callable)
objects.

The python package name may be different from the name the package is registered under in plugs. This allows to load different
python packages for a specific feature based on a configuration file. Note: Python package are still loaded as regular
python packages and can be accessed by normal means

If you want to provide additional functionality to the same feature (probably even for run-time switching)
you can implement a Factory Pattern using this package. Take a look at volume.py as an example.

**Example:** Decorate a function for auto-registering under it's own name:


**Example:** Decorate a function for auto-registering under a new name::

@plugs.register(name='better_name')
def func2(param):
pass

**Example:** Register a function during run-time under it's own name::

def func3(param):
pass
plugs.register(func3)

**Example:** Register a function during run-time under a new name::

def func4(param):
pass
plugs.register(func4, name='other_name', package='other_package')

**Example:** Decorate a class for auto registering during initialization,
including all methods (see _register_class for more info)::

@plugs.register(auto_tag=True)
class MyClass1:
pass

**Example:** Register a class instance, from which only report is a callable method through the plugs interface::

class MyClass2:
@plugs.tag
def report(self):
pass
myinst2 = MyClass2()
plugin.register(myinst2, name='myinst2')

Naming convention:

package
1. Either a python package
2. or a plugin package (which is the python package but probably loaded under a different name inside plugs)

plugin
1. An object from the package that can be accessed through the plugs call function (i.e. a function or a class instance)
2. The string name to above object

name
The string name of the plugin object for registration

method
1. In case the object is a class instance a bound method to call from the class instance
2. The string name to above object
```python
    import jukebox.plugs as plugs
    @plugs.register
    def func1(param):
        pass
```

Expected behavior

I would expect that the code sample remains at the correct position withion the docstring documentation.

A clear and concise description of what you expected to happen.

[s-martin]

Ok, found the problem.

Needed to explicitly specify - type: sphinx as processor. Afterwards I had to use rst syntax for code samples (identation)