Fixed more spacing issues

docs/Bindless.md

@@ -11,4 +11,4 @@ Daxa's bindless approach eliminates these limitations by allowing shaders to acc
 1. Improved performance: With bindless resources, shaders can access resources more efficiently, reducing the overhead associated with frequent binding and unbinding operations.
 2. Simpler code: No management of descriptor pools, set-layouts, set-allocation, set-writes, set-binding points, or sync on set-allocations.
 3. Flexibility: Bindless resources make working with dynamic and large datasets easier, as shaders can access any resource resources by handle.
-4. Less error-prone: Compared to typical Vulkan and Dx12 descriptor management systems, Daxa's bindless has such a small API surface that misuse and errors are less likely. 
+4. Less error-prone: Compared to typical Vulkan and Dx12 descriptor management systems, Daxa's bindless has such a small API surface that misuse and errors are less likely.

docs/Device.md

@@ -42,7 +42,7 @@ device.submit_commands({
     .wait_binary_semaphores = std::array{sema},
     .signal_timeline_semaphores = std::array{std::pair{tsema, tsema_value}},
 });
-``` 
+```
 
 This generally reduces boilerplate and conveniently merges the VkDevice and VkQeueue concepts.
 

docs/PipelineManager.md

@@ -71,18 +71,20 @@ PipelineManager is the container of all these pipelines, so we only give the use
 > Note: This design decision is mainly due to pipeline manager being a utility designed around developing your application, not for shipping it!
 
 #### Hot Reloading
+
 The most significant feature of PipelineManager is the hot-reloading. When the shader code is changed and saved, it will recompile the pipeline. You can even `#include` headers in your shaders, and when the code in those files is updated, the PipelineManager will automatically recompile the affected pipelines for you.
 
 To use hot-reloading, we could demonstrate this by adding a `#include` to our `ShaderCode` string. Instead, to show them more directly, we will use real or virtual files. We'll review both in this document, but let's start with the actual files. We'll create a simple Daxa project structured like so:
 
-```
+```text
 my_daxa_project/
   |- src/
   |  |- main.cpp
   |  |- main.glsl
   |- CMakeLists.txt
   | ...
 ```
+
 > Note: We'll also be using the `my_daxa_project/` directory as the CWD when launching the application. This is important since all relative paths will be relative to the CWD. To be extra clear, with this CWD, we can address the CMakeLists.txt file by saying `./CMakeLists.txt`.
 
 Now, to use `main.glsl` as our shader source file, we need to give its path to the `ShaderCompileInfo` when adding a new pipeline, so we'll do that instead. Since we want to use a relative path, we'll say `.source = daxa::ShaderFile{"src/main.glsl"}`. If we didn't specify the full relative path, then our error check from earlier would print the following:
@@ -146,6 +148,7 @@ Now is a good time to mention the Daxa shader files, which you can and should #i
 ```
 
 Once we have this root path, we can change our `main.glsl` file like this!
+
 ```cpp
 #include <daxa/daxa.inl>
 
@@ -205,4 +208,4 @@ auto compilation_result = pipeline_manager.add_compute_pipeline({
     .shader_info = {.source = daxa::ShaderFile{"my_file"}},
     .name = APPNAME_PREFIX("compute_pipeline"),
 });
-```
+```