Merge pull request #41 from membraneframework/fix/code_snippes_styling

removing extra line at some code snippets

Author: blazpie

basic_pipeline/03_Source.md

@@ -27,7 +27,6 @@ defmodule Basic.Elements.Source do
  alias Basic.Formats.Packet
  ...
 end
-
 ```
 
 ## Pads and options
@@ -43,7 +42,6 @@ defmodule Basic.Elements.Source do
  def_output_pad :output, [caps: {Packet, type: :custom_packets}, mode: :pull]
  ...
 end
-
 ```
 
 The first macro, `def_options` allows us to define the parameters which are expected to be passed while instantiating the element. The parameters will be passed as an automatically generated structure `%Basic.Elements.Source{}`. In our case, we will have a `:location` field inside of that structure. This parameter is about to be a path to the files which will contain input [packets](../glossary/glossary.md#packet).
@@ -114,7 +112,6 @@ defmodule Basic.Elements.Source do
  end
  ...
 end
-
 ```
 
 In the case of the first callback, `handle_stopped_to_prepared/2`, what we do is that we are reading the file from the location specified in the options structure (which we have saved in the state of the element).
@@ -147,7 +144,6 @@ defmodule Basic.Elements.Source do
  end
  ...
 end
-
 ```
 
 The callback's body describes the situation in which some buffers were requested. Then we are checking if we have any packets left in the list persisting in the state of the element. If that list is empty, we are sending an `end_of_stream` action, indicating that there will be no more buffers sent through the `:output` pad and that is why there is no point in requesting more buffers.

basic_pipeline/07_Redemands.md

@@ -37,7 +37,6 @@ def handle_demand(:output, _size, unit, context, state) do
  actions = [buffer: %Membrane.Buffer(payload: payload), redemand: :output]
  { {:ok, actions}, state}
 end
-
 ```
 
 ## In Filter elements

basic_pipeline/11_Pipeline.md

@@ -27,13 +27,12 @@ Please add the following callback signature to our `Basic.Pipeline` module:
 ```Elixir
 
 defmodule Basic.Pipeline do
- ... 
+ ...
  @impl true
  def handle_init(_opts) do
 
  end
 end
-
 ```
 
 As you can see, we can initialize the pipeline with some options, but in our case, we do not need them.

basic_pipeline_extension/03_DynamicPads.md

@@ -16,7 +16,7 @@ def handle_init(_opts) do
     depayloader3: %Basic.Elements.Depayloader{packets_per_frame: 4},
     ...
 }
- 
+
  links = [
     ...
     link(:input3) |> to(:ordering_buffer3) |> to(:depayloader3),

videoroom/5_ImplementingServerRoom.md

@@ -5,6 +5,7 @@ The room should dispatch messages sent from RTC Engine to appropriate peer chann
 Let's start by creating `lib/videoroom/room.ex` file with a declaration of Videoroom.Room module:
 
 **_`lib/videoroom/room.ex`_**
+
 ```elixir
 defmodule Videoroom.Room do
 @moduledoc false
@@ -24,6 +25,7 @@ We will be using OTP's [GenServer](https://elixir-lang.org/getting-started/mix-o
 Let's start by adding wrappers for GenServer's `start` and `start_link` functions:
 
 **_`lib/videoroom/room.ex`_**
+
 ```elixir
 def start(init_arg, opts) do
  GenServer.start(__MODULE__, init_arg, opts)
@@ -37,6 +39,7 @@ end
 Then we are providing the implementation of `init/1` callback:
 
 **_`lib/videoroom/room.ex`_**
+
 ```elixir
 @impl true
 def init(room_id) do
@@ -166,7 +169,6 @@ def handle_info(%Message.PeerLeft{peer: peer}, state) do
  Membrane.Logger.info("Peer #{inspect(peer.id)} left RTC Engine")
  {:noreply, state}
 end
-
 ```
 
 In case RTC Engine wants to communicate with the client during the [signaling](../glossary/glossary.md#signaling) process, we know how to react - we are simply passing the message to the appropriate `PeerChannel`.