diff --git a/.gitignore b/.gitignore
index 91c99c2..267697e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,4 @@
-*.o
-/build
-/build/*
-parser
+*.o
+/build
+/build/*
+parser
diff --git a/.vscode/settings.json b/.vscode/settings.json
new file mode 100644
index 0000000..1eaa062
--- /dev/null
+++ b/.vscode/settings.json
@@ -0,0 +1,3 @@
+{
+    "C_Cpp.errorSquiggles": "disabled"
+}
\ No newline at end of file
diff --git a/LICENSE b/LICENSE
index 6f77695..7d9756f 100644
--- a/LICENSE
+++ b/LICENSE
@@ -1,9 +1,9 @@
-MIT License
-
-Copyright (c) 2025 azpect
-
-Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+MIT License
+
+Copyright (c) 2025 azpect
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
diff --git a/Makefile b/Makefile
index e11f80d..4f8f571 100644
--- a/Makefile
+++ b/Makefile
@@ -1,49 +1,49 @@
-# Define the C++ compiler and flags
-CXX = g++
-CXXFLAGS = -Wall -g
-
-# Directories
-BUILD_DIR = build
-SRC_DIR = src
-LIB_DIR = lib
-
-# Executable name
-TARGET = parser
-
-# Automatically find all source files
-SRC_FILES := $(wildcard $(SRC_DIR)/*.cpp)
-LIB_FILES := $(wildcard $(LIB_DIR)/*.cpp)
-ALL_SOURCES = $(SRC_FILES) $(LIB_FILES)
-
-# Generate object file paths in the build directory
-OBJECTS := $(patsubst %.cpp, $(BUILD_DIR)/%.o, $(notdir $(ALL_SOURCES)))
-
-# Include directories
-INCLUDES = -I$(LIB_DIR) -I$(SRC_DIR)
-
-.PHONY: all clean test
-
-all: $(BUILD_DIR) $(TARGET)
-
-$(BUILD_DIR):
-	mkdir -p $(BUILD_DIR)
-
-$(TARGET): $(OBJECTS)
-	$(CXX) $(CXXFLAGS) $(INCLUDES) $^ -o $@
-
-# Generic rule for all .cpp files in the src/ directory
-$(BUILD_DIR)/%.o: $(SRC_DIR)/%.cpp
-	$(CXX) $(CXXFLAGS) $(INCLUDES) -c $< -o $@
-
-# Generic rule for all .cpp files in the lib/ directory
-$(BUILD_DIR)/%.o: $(LIB_DIR)/%.cpp
-	$(CXX) $(CXXFLAGS) $(INCLUDES) -c $< -o $@
-
-test: all
-	./$(TARGET)
-	./$(TARGET) '   '
-	./$(TARGET) ./test/input.md
-	./$(TARGET) ./test/input.md ./test/output.html
-
-clean:
-	rm -rf $(BUILD_DIR) $(TARGET)
+# Define the C++ compiler and flags
+CXX = g++
+CXXFLAGS = -Wall -g
+
+# Directories
+BUILD_DIR = build
+SRC_DIR = src
+LIB_DIR = lib
+
+# Executable name
+TARGET = parser
+
+# Automatically find all source files
+SRC_FILES := $(wildcard $(SRC_DIR)/*.cpp)
+LIB_FILES := $(wildcard $(LIB_DIR)/*.cpp)
+ALL_SOURCES = $(SRC_FILES) $(LIB_FILES)
+
+# Generate object file paths in the build directory
+OBJECTS := $(patsubst %.cpp, $(BUILD_DIR)/%.o, $(notdir $(ALL_SOURCES)))
+
+# Include directories
+INCLUDES = -I$(LIB_DIR) -I$(SRC_DIR)
+
+.PHONY: all clean test
+
+all: $(BUILD_DIR) $(TARGET)
+
+$(BUILD_DIR):
+	mkdir -p $(BUILD_DIR)
+
+$(TARGET): $(OBJECTS)
+	$(CXX) $(CXXFLAGS) $(INCLUDES) $^ -o $@
+
+# Generic rule for all .cpp files in the src/ directory
+$(BUILD_DIR)/%.o: $(SRC_DIR)/%.cpp
+	$(CXX) $(CXXFLAGS) $(INCLUDES) -c $< -o $@
+
+# Generic rule for all .cpp files in the lib/ directory
+$(BUILD_DIR)/%.o: $(LIB_DIR)/%.cpp
+	$(CXX) $(CXXFLAGS) $(INCLUDES) -c $< -o $@
+
+test: all
+	./$(TARGET)
+	./$(TARGET) '   '
+	./$(TARGET) ./test/input.md
+	./$(TARGET) ./test/input.md ./test/output.html
+
+clean:
+	rm -rf $(BUILD_DIR) $(TARGET)
diff --git a/README.md b/README.md
index 77ed442..06a2bb5 100644
--- a/README.md
+++ b/README.md
@@ -1,115 +1,115 @@
-# MarkdownToHtmlCompiler
-
-### Project Overview 
-
-The goal is to create a program that reads a file containing text formatted in a simple version of 
-Markdown and converts it into a valid HTML file. The program will need to identify and translate 
-specific syntax (e.g., `# Heading` to `<h1>Heading</h1>`, `*text*` to `<em>text</em>`).
-
-
-### Implementation Requirements (Generated by Gemini)
-
-Class Hierarchy: Design a class hierarchy to represent the components of your Markdown document. An 
-abstract base class, Element, can define common behavior. Derived classes would then represent specific 
-types of elements, such as Heading, Paragraph, BoldText, and ListItem. This is a perfect example of 
-inheritance and polymorphism.
-
-Object Composition: A Document class can be composed of multiple Element objects, representing the 
-entire file. A Parser class would be composed of helper methods to break down the input string and 
-build the Document object. This shows how you can build a complex system from smaller, self-contained
-objects.
-
-File I/O and Exceptions: You will need to use ifstream to read the Markdown file and ofstream to write
-the generated HTML file. Your code should use exceptions to gracefully handle potential errors, such 
-as a file not being found.
-
-Operator Overloading: Overload the << stream insertion operator for your Element and Document classes.
-This would allow you to easily print the generated HTML to the console or write it to a file, making 
-your code cleaner and more readable.
-
-UML Diagram: The complexity of the class relationships makes a UML diagram an essential part of the 
-project. It will help you plan your design and will be a key component of your submission.
-
-Recursive Descent Parser: This is the primary algorithm you'll use. It's a top-down parsing technique
-where a set of recursive functions "descend" through the grammar of your simple Markdown language. For
-example, a parse_document() function would call parse_line(), which in turn might call parse_bold_text()
-or parse_italic_text(). This method is intuitive and easy to implement for a simple grammar.
-
-Stack: A stack is essential for handling nested elements. For instance, if you allow bold text inside
-italic text (_This is *bold and italic* text_), you can push the _ token onto the stack and then push
-the * token. When you encounter the closing *, you check if the top of the stack matches. This ensures
-that all tags are correctly opened and closed. Your presentation can visually demonstrate this process
-with a stack diagram.
-
-Hash Map or Map: A hash map (std::unordered_map) or a map (std::map) can be used to efficiently store
-and retrieve the HTML equivalent for each Markdown tag. For example, you could map `#` to `<h1>`or `*`
-to `<em>`. This provides O(1) average-case lookup time.
-
-
-### Contribution Policy
-
-###### Branching
-When working on this project, please use a feature branch (i.e. `feature/parser`) with a descriptive name.
-`feature/a` is not a descriptive name. These branches should be branched off the most recent `main` branch,
-we will not make use of a `dev` or `staging` branch since the project is small in scale as well as time.
-**However, if the project becomes larger or out-of-control, a dev/staging branch will be implemented.**
-
-###### Commits
-
-When working, it is best practice to commit code as much as possible, without being over zealous. For 
-example, when a feature or bug is complete, its time to commit. But when you have to make a new function,
-that does not mean its time. Each team member should use their best judgment.
-
-Commit messages a little bit more important, when working in a team, it is important to provide strong,
-clear and concise commit messages. In this project, the team will use a simple formula:
-
-**(SUBJECT) Title: textual description** 
-
-i.e. (FIX) Rendering completed: explain what changed in short.
-
-###### Pushing
-
-When working in a feature branch, pushing and pulling has no restrictions. Feel free to do as much 
-(or as little) as possible. However, you **CANNOT** push directly to `main`, the VCS will not allow you
-to do so, but do not make that mistake. When you are ready to merge a feature, you will create a PR
-and once it has been reviewed and approved it will be automatically merged in.
-
-###### Pull Requests (PR)
-
-Once a feature is complete, you will create a pull request. Before a request can be merged into `main`,
-one approval is required (which cannot be the author). This practice is to promote team work and encourage
-code reviews. Each team member is expected to check in frequently and review as often as they are able to,
-however, there is no defined time requirement. Personal communication is totally acceptable as a means to 
-request approval, since I am unsure if this platform will notify members.
-
-###### Issues
-
-If a bug, issue, or otherwise concern is noticed the first thing the team member should do is create an 
-issue. An issue should be descriptive and contain everything another team member needs to understand the 
-issue and its context. This way, a new team member can tackle the issue without contextual gaps.
-
-If a member would like to work on the issue themself, the `assignee` field is where this should be defined.
-If a member would like help from another member, they should assign the other team member to the issue, and 
-leave a comment in the issue itself describing what help is needed. 
-
-**Labels** are important for understanding what type of issues/bugs exist in the application. When a bug is 
-created, make sure the proper labels are applied. These labels will be abstract, such as: `bug`, `fix` or `feature`
-and they will also be specific, such as: `parser`, `i/o` or `processer`. A combination of both styles of labels
-allows other team members to understand what is going on. If a member feels an issue is missing, they are free
-to create new ones, but there is a such thing as **too many labels** a few per issue is totally fine. They are
-not meant to replace the description.
-
-**Priority** is the final important factor to consider. In this project, priority will be defined using labels
-as well. The policy defined above will apply here to priority labels as well. However, these labels are 
-**mutually exclusive**.
-
-###### Projects (Sprints)
-
-The use of the `projects` tab in the VCS will allow the team to remain organized as create notes and action 
-items that should be completed before one another. These resemble `sprints` from the `AGILE` development life cycle.
-A new "project" should be created when a large piece of functionality needs to be created. Issues can **and should**
-be attached to the projects they are related too. This will continue to encourage teamwork and organization.
-
-Projects should have defined criteria, such as input and outputs, expectations and a semi-defined timeline. 
-Once a description and is defined, tasks can be added and moved around as needed. The team will use **Kanban**
-project types, as they are simple and easy to understand for new team members.
+# MarkdownToHtmlCompiler
+
+### Project Overview 
+
+The goal is to create a program that reads a file containing text formatted in a simple version of 
+Markdown and converts it into a valid HTML file. The program will need to identify and translate 
+specific syntax (e.g., `# Heading` to `<h1>Heading</h1>`, `*text*` to `<em>text</em>`).
+
+
+### Implementation Requirements (Generated by Gemini)
+
+Class Hierarchy: Design a class hierarchy to represent the components of your Markdown document. An 
+abstract base class, Element, can define common behavior. Derived classes would then represent specific 
+types of elements, such as Heading, Paragraph, BoldText, and ListItem. This is a perfect example of 
+inheritance and polymorphism.
+
+Object Composition: A Document class can be composed of multiple Element objects, representing the 
+entire file. A Parser class would be composed of helper methods to break down the input string and 
+build the Document object. This shows how you can build a complex system from smaller, self-contained
+objects.
+
+File I/O and Exceptions: You will need to use ifstream to read the Markdown file and ofstream to write
+the generated HTML file. Your code should use exceptions to gracefully handle potential errors, such 
+as a file not being found.
+
+Operator Overloading: Overload the << stream insertion operator for your Element and Document classes.
+This would allow you to easily print the generated HTML to the console or write it to a file, making 
+your code cleaner and more readable.
+
+UML Diagram: The complexity of the class relationships makes a UML diagram an essential part of the 
+project. It will help you plan your design and will be a key component of your submission.
+
+Recursive Descent Parser: This is the primary algorithm you'll use. It's a top-down parsing technique
+where a set of recursive functions "descend" through the grammar of your simple Markdown language. For
+example, a parse_document() function would call parse_line(), which in turn might call parse_bold_text()
+or parse_italic_text(). This method is intuitive and easy to implement for a simple grammar.
+
+Stack: A stack is essential for handling nested elements. For instance, if you allow bold text inside
+italic text (_This is *bold and italic* text_), you can push the _ token onto the stack and then push
+the * token. When you encounter the closing *, you check if the top of the stack matches. This ensures
+that all tags are correctly opened and closed. Your presentation can visually demonstrate this process
+with a stack diagram.
+
+Hash Map or Map: A hash map (std::unordered_map) or a map (std::map) can be used to efficiently store
+and retrieve the HTML equivalent for each Markdown tag. For example, you could map `#` to `<h1>`or `*`
+to `<em>`. This provides O(1) average-case lookup time.
+
+
+### Contribution Policy
+
+###### Branching
+When working on this project, please use a feature branch (i.e. `feature/parser`) with a descriptive name.
+`feature/a` is not a descriptive name. These branches should be branched off the most recent `main` branch,
+we will not make use of a `dev` or `staging` branch since the project is small in scale as well as time.
+**However, if the project becomes larger or out-of-control, a dev/staging branch will be implemented.**
+
+###### Commits
+
+When working, it is best practice to commit code as much as possible, without being over zealous. For 
+example, when a feature or bug is complete, its time to commit. But when you have to make a new function,
+that does not mean its time. Each team member should use their best judgment.
+
+Commit messages a little bit more important, when working in a team, it is important to provide strong,
+clear and concise commit messages. In this project, the team will use a simple formula:
+
+**(SUBJECT) Title: textual description** 
+
+i.e. (FIX) Rendering completed: explain what changed in short.
+
+###### Pushing
+
+When working in a feature branch, pushing and pulling has no restrictions. Feel free to do as much 
+(or as little) as possible. However, you **CANNOT** push directly to `main`, the VCS will not allow you
+to do so, but do not make that mistake. When you are ready to merge a feature, you will create a PR
+and once it has been reviewed and approved it will be automatically merged in.
+
+###### Pull Requests (PR)
+
+Once a feature is complete, you will create a pull request. Before a request can be merged into `main`,
+one approval is required (which cannot be the author). This practice is to promote team work and encourage
+code reviews. Each team member is expected to check in frequently and review as often as they are able to,
+however, there is no defined time requirement. Personal communication is totally acceptable as a means to 
+request approval, since I am unsure if this platform will notify members.
+
+###### Issues
+
+If a bug, issue, or otherwise concern is noticed the first thing the team member should do is create an 
+issue. An issue should be descriptive and contain everything another team member needs to understand the 
+issue and its context. This way, a new team member can tackle the issue without contextual gaps.
+
+If a member would like to work on the issue themself, the `assignee` field is where this should be defined.
+If a member would like help from another member, they should assign the other team member to the issue, and 
+leave a comment in the issue itself describing what help is needed. 
+
+**Labels** are important for understanding what type of issues/bugs exist in the application. When a bug is 
+created, make sure the proper labels are applied. These labels will be abstract, such as: `bug`, `fix` or `feature`
+and they will also be specific, such as: `parser`, `i/o` or `processer`. A combination of both styles of labels
+allows other team members to understand what is going on. If a member feels an issue is missing, they are free
+to create new ones, but there is a such thing as **too many labels** a few per issue is totally fine. They are
+not meant to replace the description.
+
+**Priority** is the final important factor to consider. In this project, priority will be defined using labels
+as well. The policy defined above will apply here to priority labels as well. However, these labels are 
+**mutually exclusive**.
+
+###### Projects (Sprints)
+
+The use of the `projects` tab in the VCS will allow the team to remain organized as create notes and action 
+items that should be completed before one another. These resemble `sprints` from the `AGILE` development life cycle.
+A new "project" should be created when a large piece of functionality needs to be created. Issues can **and should**
+be attached to the projects they are related too. This will continue to encourage teamwork and organization.
+
+Projects should have defined criteria, such as input and outputs, expectations and a semi-defined timeline. 
+Once a description and is defined, tasks can be added and moved around as needed. The team will use **Kanban**
+project types, as they are simple and easy to understand for new team members.
diff --git a/flake.lock b/flake.lock
index 5cc6d19..4944b4c 100644
--- a/flake.lock
+++ b/flake.lock
@@ -1,61 +1,61 @@
-{
-  "nodes": {
-    "flake-utils": {
-      "inputs": {
-        "systems": "systems"
-      },
-      "locked": {
-        "lastModified": 1731533236,
-        "narHash": "sha256-l0KFg5HjrsfsO/JpG+r7fRrqm12kzFHyUHqHCVpMMbI=",
-        "owner": "numtide",
-        "repo": "flake-utils",
-        "rev": "11707dc2f618dd54ca8739b309ec4fc024de578b",
-        "type": "github"
-      },
-      "original": {
-        "owner": "numtide",
-        "repo": "flake-utils",
-        "type": "github"
-      }
-    },
-    "nixpkgs": {
-      "locked": {
-        "lastModified": 1760284886,
-        "narHash": "sha256-TK9Kr0BYBQ/1P5kAsnNQhmWWKgmZXwUQr4ZMjCzWf2c=",
-        "owner": "NixOS",
-        "repo": "nixpkgs",
-        "rev": "cf3f5c4def3c7b5f1fc012b3d839575dbe552d43",
-        "type": "github"
-      },
-      "original": {
-        "owner": "NixOS",
-        "ref": "nixos-unstable",
-        "repo": "nixpkgs",
-        "type": "github"
-      }
-    },
-    "root": {
-      "inputs": {
-        "flake-utils": "flake-utils",
-        "nixpkgs": "nixpkgs"
-      }
-    },
-    "systems": {
-      "locked": {
-        "lastModified": 1681028828,
-        "narHash": "sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768=",
-        "owner": "nix-systems",
-        "repo": "default",
-        "rev": "da67096a3b9bf56a91d16901293e51ba5b49a27e",
-        "type": "github"
-      },
-      "original": {
-        "owner": "nix-systems",
-        "repo": "default",
-        "type": "github"
-      }
-    }
-  },
-  "root": "root",
-  "version": 7
-}
+{
+  "nodes": {
+    "flake-utils": {
+      "inputs": {
+        "systems": "systems"
+      },
+      "locked": {
+        "lastModified": 1731533236,
+        "narHash": "sha256-l0KFg5HjrsfsO/JpG+r7fRrqm12kzFHyUHqHCVpMMbI=",
+        "owner": "numtide",
+        "repo": "flake-utils",
+        "rev": "11707dc2f618dd54ca8739b309ec4fc024de578b",
+        "type": "github"
+      },
+      "original": {
+        "owner": "numtide",
+        "repo": "flake-utils",
+        "type": "github"
+      }
+    },
+    "nixpkgs": {
+      "locked": {
+        "lastModified": 1760284886,
+        "narHash": "sha256-TK9Kr0BYBQ/1P5kAsnNQhmWWKgmZXwUQr4ZMjCzWf2c=",
+        "owner": "NixOS",
+        "repo": "nixpkgs",
+        "rev": "cf3f5c4def3c7b5f1fc012b3d839575dbe552d43",
+        "type": "github"
+      },
+      "original": {
+        "owner": "NixOS",
+        "ref": "nixos-unstable",
+        "repo": "nixpkgs",
+        "type": "github"
+      }
+    },
+    "root": {
+      "inputs": {
+        "flake-utils": "flake-utils",
+        "nixpkgs": "nixpkgs"
+      }
+    },
+    "systems": {
+      "locked": {
+        "lastModified": 1681028828,
+        "narHash": "sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768=",
+        "owner": "nix-systems",
+        "repo": "default",
+        "rev": "da67096a3b9bf56a91d16901293e51ba5b49a27e",
+        "type": "github"
+      },
+      "original": {
+        "owner": "nix-systems",
+        "repo": "default",
+        "type": "github"
+      }
+    }
+  },
+  "root": "root",
+  "version": 7
+}
diff --git a/flake.nix b/flake.nix
index 351e25c..e544aa4 100644
--- a/flake.nix
+++ b/flake.nix
@@ -1,42 +1,42 @@
-{
-  description = "Blank development flake. Adjust as needed";
-
-  inputs = {
-    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
-    flake-utils.url = "github:numtide/flake-utils";
-  };
-
-  outputs = { self, nixpkgs, flake-utils, ... }:
-    flake-utils.lib.eachDefaultSystem (system:
-      let
-        pkgs = import nixpkgs { inherit system; };
-      in
-      {
-        # Define the development shell.
-        # When you run `nix develop` (or direnv activates), you'll enter this shell.
-        devShells.default = pkgs.mkShell {
-          # List all the development tools you need available in this shell's PATH.
-          packages = with pkgs; [
-            gcc
-            gdb
-            stdenv
-          ];
-
-          # Define the shell that will be executed.
-          # Here, we explicitly use zsh.
-          # Note: pkgs.zsh needs to be included in `packages` or `nativeBuildInputs`
-          # for it to be found in the shell's environment. `inherit pkgs.zsh;` is concise.
-          inherit (pkgs) zsh;
-
-          # Environment variables and commands to run when the shell starts.
-          shellHook = ''
-            # Add any exports, hooks, aliases, or anything else here
-
-            # Exec zsh to replace the current shell process with zsh.
-            # This ensures your prompt and zsh configurations load correctly.
-            exec zsh
-          '';
-        };
-      }
-    );
-}
+{
+  description = "Blank development flake. Adjust as needed";
+
+  inputs = {
+    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
+    flake-utils.url = "github:numtide/flake-utils";
+  };
+
+  outputs = { self, nixpkgs, flake-utils, ... }:
+    flake-utils.lib.eachDefaultSystem (system:
+      let
+        pkgs = import nixpkgs { inherit system; };
+      in
+      {
+        # Define the development shell.
+        # When you run `nix develop` (or direnv activates), you'll enter this shell.
+        devShells.default = pkgs.mkShell {
+          # List all the development tools you need available in this shell's PATH.
+          packages = with pkgs; [
+            gcc
+            gdb
+            stdenv
+          ];
+
+          # Define the shell that will be executed.
+          # Here, we explicitly use zsh.
+          # Note: pkgs.zsh needs to be included in `packages` or `nativeBuildInputs`
+          # for it to be found in the shell's environment. `inherit pkgs.zsh;` is concise.
+          inherit (pkgs) zsh;
+
+          # Environment variables and commands to run when the shell starts.
+          shellHook = ''
+            # Add any exports, hooks, aliases, or anything else here
+
+            # Exec zsh to replace the current shell process with zsh.
+            # This ensures your prompt and zsh configurations load correctly.
+            exec zsh
+          '';
+        };
+      }
+    );
+}
diff --git a/lib/inlindeNode.h b/lib/inlindeNode.h
new file mode 100644
index 0000000..09e5d13
--- /dev/null
+++ b/lib/inlindeNode.h
@@ -0,0 +1,17 @@
+#ifndef INLINENODE_H
+#define INLINENODE_H
+#include "node.h"
+
+class InlineNode : public Node{
+    public:
+        InlineNode(std::string content) : content(content);
+    protected:
+        std::string content;
+};
+
+class TextNode : public InlineNode{};
+class BoldNode : public InlineNode{};
+class Italic : public InlineNode{};
+class BoldItalic : public InlineNode{};
+
+#endif 
diff --git a/lib/inlineNode.cpp b/lib/inlineNode.cpp
new file mode 100644
index 0000000..e69de29
diff --git a/lib/node.cpp b/lib/node.cpp
index 0ed30f8..d1a373b 100644
--- a/lib/node.cpp
+++ b/lib/node.cpp
@@ -1,4 +1,4 @@
-#include "./node.h"
+#include "node.h"
 
 #include <iostream>
 #include <memory>
diff --git a/lib/node.h b/lib/node.h
index 47a3918..9ee7023 100644
--- a/lib/node.h
+++ b/lib/node.h
@@ -1,71 +1,71 @@
-#ifndef NODE_H
-#define NODE_H
-
-#include <memory>
-#include <string>
-#include <vector>
-
-/// NOTE: What the heck are unique pointers (unique_ptrs)
-/// They are basically an abstraction over the typical (raw) pointer.
-/// They handle ownership and deletion of the pointer for us, to prevent memory
-/// leaks.
-/// They are pretty easy to use, and only need to exist in places where new ones
-/// are created. i.e., functions should not accept unique_ptrs, instead they
-/// should accept normal pointers or references.
-/// When calling a function that accepts a raw pointer, the unique_ptrs.get()
-/// method is required. When calling a function that accepts a reference, the
-/// reference operator (*) works perfectly fine. Hence, in this project we will
-/// try to avoid using raw pointers, and only use references when needed.
-
-// NOTE ABC
-class Node {
-protected:
-  /**
-   * @brief List of children nodes.
-   *
-   * Most nodes will not have children, but some may, therefore this class must
-   * have it.
-   *
-   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
-   */
-  std::vector<std::unique_ptr<Node>> children;
-
-public:
-  /**
-   * @brief Inspect (view) the contents of the Node.
-   *
-   * This is a recursive approach to allow for indentation for easier viewing.
-   *
-   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
-   */
-  virtual void Inspect(int indent = 0);
-
-  /**
-   * @brief Return the node as a string.
-   *
-   * In this ABC the content is just returned with no modifications. The child
-   * nodes are expected to modify this behavior. i.e. wrapping in HTML tags.
-   *
-   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
-   */
-  virtual std::string ToHtml() const = 0;
-
-  virtual void AddChild(std::unique_ptr<Node> child) {
-    // Move ownership from the existing owner, to this class
-    this->children.push_back(std::move(child));
-  }
-
-  /**
-   * @brief Return a read-only (const) list of children.
-   *
-   * Return our list of unique ptrs, they are const and therefore only have read
-   * access.
-   *
-   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
-   */
-  virtual const std::vector<std::unique_ptr<Node>> &GetChilren() const {
-    return this->children;
-  }
-};
-
-#endif
+#ifndef NODE_H
+#define NODE_H
+
+#include <memory>
+#include <string>
+#include <vector>
+
+/// NOTE: What the heck are unique pointers (unique_ptrs)
+/// They are basically an abstraction over the typical (raw) pointer.
+/// They handle ownership and deletion of the pointer for us, to prevent memory
+/// leaks.
+/// They are pretty easy to use, and only need to exist in places where new ones
+/// are created. i.e., functions should not accept unique_ptrs, instead they
+/// should accept normal pointers or references.
+/// When calling a function that accepts a raw pointer, the unique_ptrs.get()
+/// method is required. When calling a function that accepts a reference, the
+/// reference operator (*) works perfectly fine. Hence, in this project we will
+/// try to avoid using raw pointers, and only use references when needed.
+
+// NOTE ABC
+class Node {
+protected:
+  /**
+   * @brief List of children nodes.
+   *
+   * Most nodes will not have children, but some may, therefore this class must
+   * have it.
+   *
+   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
+   */
+  std::vector<std::unique_ptr<Node>> children;
+
+public:
+  /**
+   * @brief Inspect (view) the contents of the Node.
+   *
+   * This is a recursive approach to allow for indentation for easier viewing.
+   *
+   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
+   */
+  virtual void Inspect(int indent = 0);
+
+  /**
+   * @brief Return the node as a string.
+   *
+   * In this ABC the content is just returned with no modifications. The child
+   * nodes are expected to modify this behavior. i.e. wrapping in HTML tags.
+   *
+   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
+   */
+  virtual std::string ToHtml() const = 0;
+
+  virtual void AddChild(std::unique_ptr<Node> child) {
+    // Move ownership from the existing owner, to this class
+    this->children.push_back(std::move(child));
+  }
+
+  /**
+   * @brief Return a read-only (const) list of children.
+   *
+   * Return our list of unique ptrs, they are const and therefore only have read
+   * access.
+   *
+   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
+   */
+  virtual const std::vector<std::unique_ptr<Node>> &GetChilren() const {
+    return this->children;
+  }
+};
+
+#endif
diff --git a/lib/parser.cpp b/lib/parser.cpp
index f2ac975..0f563e0 100644
--- a/lib/parser.cpp
+++ b/lib/parser.cpp
@@ -1,5 +1,5 @@
-#include "./parser.h"
-#include "./util.h"
+#include "parser.h"
+#include "util.h"
 #include <cctype>
 #include <stdexcept>
 
diff --git a/lib/parser.h b/lib/parser.h
index 972ccee..74ecfab 100644
--- a/lib/parser.h
+++ b/lib/parser.h
@@ -1,104 +1,104 @@
-#ifndef PARSER_H
-#define PARSER_H
-
-#include <iostream>
-#include <stack>
-#include <string>
-
-using std::string;
-
-/**
- * @brief Markdown parser class.
- *
- * Converts a Markdown file into an HTML output. This is done using a
- * recursive descent parser and converting the Markdown into a DOM tree.
- * Once the DOM tree exists, it is converted into an HTML string and
- * written to the output file provided.
- *
- * This class will have a `DOM` and a `DOMParser` which are used in this
- * process.
- *
- * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
- */
-class Parser {
-public:
-  Parser(string input_file_path, string output_file_path = "");
-
-  /**
-   * @brief Inspect (view) contents of the class.
-   *
-   * Print each member of the class in its current state. Used for debugging.
-   *
-   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
-   */
-  void Inspect();
-
-  /**
-   *
-   * @brief Parse an entire document.
-   *
-   * This function will be called to yield the result. This is the entry point
-   * to the recursive descent parser.
-   *
-   * Currently, there are no parameters, they are still under consideration.
-   *
-   * It will be important to remember states between lines. For example, a
-   * paragraph that spans many lines should be inside the same node. But
-   * white space causes the node to be broken.
-   *
-   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
-   */
-  void ParseDocument(void);
-
-protected:
-  /**
-   * @brief Input file path.
-   *
-   * Must be provided by the user.
-   *
-   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
-   */
-  string input_file_path;
-
-  /**
-   * @brief Output file path.
-   *
-   * If not provided, will be generated using the `input_file_path` by removing
-   * the extension and appending `.html`.
-   *
-   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
-   */
-  string output_file_path;
-
-  // NOTE: We need a stack, just not sure what goes in it yet
-  // std::stack<any> stack;
-
-private:
-  /**
-   * @brief Parse a single line.
-   *
-   * How does this function work...
-   * This is where the magic happens.
-   *
-   * @param line Target line to parse, as string.
-   * @return DOMNode, once exists
-   *
-   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
-   */
-  void ParseLine(string line);
-
-  // NOTE: Parser operations, again, abstract, just for brainstorming now
-  //       These should operate on internal state, not lines themselves
-  void ParseHeader();
-  void ParseParagraph();
-  void ParseItalic();
-  void ParseBold();
-  void ParseBoldItalic();
-
-  // NOTE: Character operations, these are just for brainstorming
-  char Peek();
-  void Consume();
-  bool EndOfLine();
-};
-
-#endif
+#ifndef PARSER_H
+#define PARSER_H
+
+#include <iostream>
+#include <stack>
+#include <string>
+
+using std::string;
+
+/**
+ * @brief Markdown parser class.
+ *
+ * Converts a Markdown file into an HTML output. This is done using a
+ * recursive descent parser and converting the Markdown into a DOM tree.
+ * Once the DOM tree exists, it is converted into an HTML string and
+ * written to the output file provided.
+ *
+ * This class will have a `DOM` and a `DOMParser` which are used in this
+ * process.
+ *
+ * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
+ */
+class Parser {
+public:
+  Parser(string input_file_path, string output_file_path = "");
+
+  /**
+   * @brief Inspect (view) contents of the class.
+   *
+   * Print each member of the class in its current state. Used for debugging.
+   *
+   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
+   */
+  void Inspect();
+
+  /**
+   *
+   * @brief Parse an entire document.
+   *
+   * This function will be called to yield the result. This is the entry point
+   * to the recursive descent parser.
+   *
+   * Currently, there are no parameters, they are still under consideration.
+   *
+   * It will be important to remember states between lines. For example, a
+   * paragraph that spans many lines should be inside the same node. But
+   * white space causes the node to be broken.
+   *
+   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
+   */
+  void ParseDocument(void);
+
+protected:
+  /**
+   * @brief Input file path.
+   *
+   * Must be provided by the user.
+   *
+   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
+   */
+  string input_file_path;
+
+  /**
+   * @brief Output file path.
+   *
+   * If not provided, will be generated using the `input_file_path` by removing
+   * the extension and appending `.html`.
+   *
+   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
+   */
+  string output_file_path;
+
+  // NOTE: We need a stack, just not sure what goes in it yet
+  // std::stack<any> stack;
+
+private:
+  /**
+   * @brief Parse a single line.
+   *
+   * How does this function work...
+   * This is where the magic happens.
+   *
+   * @param line Target line to parse, as string.
+   * @return DOMNode, once exists
+   *
+   * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
+   */
+  void ParseLine(string line);
+
+  // NOTE: Parser operations, again, abstract, just for brainstorming now
+  //       These should operate on internal state, not lines themselves
+  void ParseHeader();
+  void ParseParagraph();
+  void ParseItalic();
+  void ParseBold();
+  void ParseBoldItalic();
+
+  // NOTE: Character operations, these are just for brainstorming
+  char Peek();
+  void Consume();
+  bool EndOfLine();
+};
+
+#endif
diff --git a/lib/structureNode.cpp b/lib/structureNode.cpp
new file mode 100644
index 0000000..6d4d8f4
--- /dev/null
+++ b/lib/structureNode.cpp
@@ -0,0 +1 @@
+#include "structureNode.h"
diff --git a/lib/structureNode.h b/lib/structureNode.h
new file mode 100644
index 0000000..576de51
--- /dev/null
+++ b/lib/structureNode.h
@@ -0,0 +1,13 @@
+#ifndef STRUCTURENODE_H
+#define STRUCTURENODE_H
+
+#include "node.h"
+
+class StructureNode : public Node {};
+
+class ListNode : public StructureNode {};
+class HeadingNode : public StructureNode {};
+class DocumentNode : public StructureNode {};
+class ParagraphNode : public StructureNode {};
+
+#endif
diff --git a/lib/util.cpp b/lib/util.cpp
index 0811048..a63a079 100644
--- a/lib/util.cpp
+++ b/lib/util.cpp
@@ -1,4 +1,4 @@
-#include "./util.h"
+#include "util.h"
 
 void removeTrailingWhitespace(std::string &input) {
   size_t start = input.find_first_not_of(" \t\n\r\f\v");
diff --git a/lib/util.h b/lib/util.h
index f773d94..d843d1b 100644
--- a/lib/util.h
+++ b/lib/util.h
@@ -1,30 +1,30 @@
-#ifndef UTIL_H
-#define UTIL_H
-
-#include <string>
-
-/**
- * @brief Remove all white space after the content.
- *
- * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
- */
-void removeTrailingWhitespace(std::string &input);
-
-/**
- * @brief Remove all white space before the content.
- *
- * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
- */
-void removeLeadingWhitespace(std::string &input);
-
-/**
- * @brief Remove all white space before and after the content.
- *
- * This uses the removeTrailingWhitespace and the removeLeadingWhitespace
- * methods together on the same string.
- *
- * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
- */
-void removeWhitespace(std::string &input);
-
-#endif
+#ifndef UTIL_H
+#define UTIL_H
+
+#include <string>
+
+/**
+ * @brief Remove all white space after the content.
+ *
+ * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
+ */
+void removeTrailingWhitespace(std::string &input);
+
+/**
+ * @brief Remove all white space before the content.
+ *
+ * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
+ */
+void removeLeadingWhitespace(std::string &input);
+
+/**
+ * @brief Remove all white space before and after the content.
+ *
+ * This uses the removeTrailingWhitespace and the removeLeadingWhitespace
+ * methods together on the same string.
+ *
+ * @author Hayden Hargreaves (hhargreaves2006@gmail.com)
+ */
+void removeWhitespace(std::string &input);
+
+#endif
diff --git a/src/main.cpp b/src/main.cpp
index 358777c..2cfd5eb 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -1,27 +1,27 @@
-#include "../lib/parser.h"
-#include <stdexcept>
-
-int main(int argc, char **argv) {
-  if (argc <= 1) {
-    std::cerr << "Usage: <input_file> <?output_file>" << std::endl;
-    return 0; // TODO: Should return 1?
-  }
-
-  try {
-    if (argc >= 3) {
-      Parser p(argv[1], argv[2]);
-      p.Inspect();
-    } else {
-      Parser p(argv[1]);
-      p.Inspect();
-    }
-  } catch (const std::runtime_error &e) {
-    std::cout << "Caught an error: " << e.what() << std::endl;
-  } catch (...) {
-    std::cout << "Caught an error: UNKNOWN" << std::endl;
-  }
-
-  std::cout << std::endl;
-
-  return 0;
-}
+#include "../lib/parser.h"
+#include <stdexcept>
+
+int main(int argc, char **argv) {
+  if (argc <= 1) {
+    std::cerr << "Usage: <input_file> <?output_file>" << std::endl;
+    return 0; // TODO: Should return 1?
+  }
+
+  try {
+    if (argc >= 3) {
+      Parser p(argv[1], argv[2]);
+      p.Inspect();
+    } else {
+      Parser p(argv[1]);
+      p.Inspect();
+    }
+  } catch (const std::runtime_error &e) {
+    std::cout << "Caught an error: " << e.what() << std::endl;
+  } catch (...) {
+    std::cout << "Caught an error: UNKNOWN" << std::endl;
+  }
+
+  std::cout << std::endl;
+
+  return 0;
+}
diff --git a/syntax.md b/syntax.md
index d965dfd..bd80e12 100644
--- a/syntax.md
+++ b/syntax.md
@@ -1,45 +1,45 @@
-
-Reference [here](https://www.markdownguide.org/basic-syntax/)
-
-Headings, h# tags
-
-
-# Header Level 1 -> <h1> Content </h1>
-## Header Level 2 -> <h2> Content </h2>
-### Header Level 3 -> <h3> Content </h3>
-#### Header Level 4 -> <h4> Content </h4>
-##### Header Level 5 -> <h5> Content </h5>
-###### Header Level 6 -> <h6> Content </h6>
-
-
-Alternate syntax (n number of =/-)
-
-Header Level 1 -> <h1> Content </h1>
-================
-
-
-Header Level 2 -> <h2> Content </h2>
-----------------
-
-
-Paragraph tags
-
-Hello world -> <p> Hello world </p>
-
-This is also
-a paragraph   -> <p> this is also a paragraph regardless </p>
-regardless 
-
-However  
-this is a break, because it ends with two spaces -> <p> However <br> this is a break, because it ends with two spaces </p>
-
-Double returns also
-
-yields new paragraphs -> <p> Double returns also</p> <p> yields new paragraphs </p>
-
-
-*italic* -> <em>italic</em>
-**bold** -> <strong>bold</strong>
-***italic bold*** -> <strong><em>italic bold</em></strong>
-
-hello **world** -> [TextClass: hello, BoldClass: world]
+
+Reference [here](https://www.markdownguide.org/basic-syntax/)
+
+Headings, h# tags
+
+
+# Header Level 1 -> <h1> Content </h1>
+## Header Level 2 -> <h2> Content </h2>
+### Header Level 3 -> <h3> Content </h3>
+#### Header Level 4 -> <h4> Content </h4>
+##### Header Level 5 -> <h5> Content </h5>
+###### Header Level 6 -> <h6> Content </h6>
+
+
+Alternate syntax (n number of =/-)
+
+Header Level 1 -> <h1> Content </h1>
+================
+
+
+Header Level 2 -> <h2> Content </h2>
+----------------
+
+
+Paragraph tags
+
+Hello world -> <p> Hello world </p>
+
+This is also
+a paragraph   -> <p> this is also a paragraph regardless </p>
+regardless 
+
+However  
+this is a break, because it ends with two spaces -> <p> However <br> this is a break, because it ends with two spaces </p>
+
+Double returns also
+
+yields new paragraphs -> <p> Double returns also</p> <p> yields new paragraphs </p>
+
+
+*italic* -> <em>italic</em>
+**bold** -> <strong>bold</strong>
+***italic bold*** -> <strong><em>italic bold</em></strong>
+
+hello **world** -> [TextClass: hello, BoldClass: world]
diff --git a/test/input.md b/test/input.md
index 03da0ea..54ed126 100644
--- a/test/input.md
+++ b/test/input.md
@@ -1,17 +1,17 @@
-
-
-# Hello world in an h1 tag
-
-
-## This is a h2 tag
-
-
-### h3
-
-
-#### h4
-
-##### h5
-
-###### h6
-
+
+
+# Hello world in an h1 tag
+
+
+## This is a h2 tag
+
+
+### h3
+
+
+#### h4
+
+##### h5
+
+###### h6
+