diff --git a/Makefile b/Makefile
index 36fc0fb..d92705c 100644
--- a/Makefile
+++ b/Makefile
@@ -26,6 +26,7 @@ OBJECT_DIR=obj
 
 # Compiler flags
 COMPILE_FLAGS=-g -fPIC --no-gnu-unique -std=c++23
+COMPILE_FLAGS+=-fdiagnostics-color=always
 COMPILE_FLAGS+=-I "/usr/include/pixman-1"
 COMPILE_FLAGS+=-I "/usr/include/libdrm"
 COMPILE_FLAGS+=-I "${HYPRLAND_HEADERS}"
diff --git a/README.md b/README.md
index d0740ea..dd4b2d0 100644
--- a/README.md
+++ b/README.md
@@ -21,6 +21,8 @@ at the top of the repository file view.
 For a code editor, I recommend VS Code or Neovim, but anything that can use Clangd will work
 If you use Clangd, `make clangd` will generate a simple `compile_flags.txt` file with the proper
 include paths and flags, which will make Clangd recognize the includes etc.
+Alternatively, use [bear](https://github.com/rizsotto/Bear) to generate `compile_commands.json`
+which is a bit more granular.
 
 > **Warning**: Compiling the plugin should still be done using GCC 12+. Clang does not properly
 > build Hyprland, and is very fussy about the hook system. You will most likely encounter errors
@@ -35,24 +37,23 @@ that.
 
 When building your own plugins for testing, you will need to manually define it using
 `export HYPRLAND_HEADERS=(PATH_TO_HYPRLAND_SOURCE_ROOT)` before running `make` commands. You
-can use a local path if you keep `Hyprland` source anyway, but I'd definitely recomment using
+can use a local path if you keep `Hyprland` source anyway, but I'd definitely recommend using
 `hyprload`. If you use your local source different from the `hyprload` one, make sure to
 run `make pluginenv` in the Hyprland folder.
 
-And here, excuse me, but I will go on a tangent about why `hyprload` is great:
-
 #### Hyprload, and why it's useful for plugin development
-If you use `hyprload`, it will keep a copy of Hyprland source code up to date with the Hyprland
-version you're running in `$HOME/.local/share/hyprload/hyprland`, and you can use that as your
+If you use `hyprload`, handing `HYPRLOAD_HEADERS` becomes a bit easier and more reliable.
+By design it keeps a copy of Hyprland source code up to date with the Hyprland version you're
+running in `$HOME/.local/share/hyprload/hyprland`, and you can use that as your
 `HYPRLAND_HEADERS` path.
 
-When installing your plugin on other people's computers, `hyprload` will automatically define
-`HYPRLAND_HEADERS` to that path to ensure maximum compatibility.
+When users install your plugin via `hyprload`, it will automatically define `HYPRLAND_HEADERS`
+to that path to ensure maximum compatibility.
 
 When developing plugins and frequently changing them, the `make install` command will
 automatically place your plugin build in the directory `hyprload` automatically loads. You can
-reload plugins when testing using the `hyprload,reload` dispatcher (bind it in your
-`hyprland.conf`
+reload plugins when testing using the `hyprload reload` dispatcher (bind it in your
+`hyprland.conf`, or execute via `hyprctl dispatch hyprload reload`)
 
 #### Making it Your Own
 To change your plugin name, version, and author (that's you!) there are 3 variables that need
@@ -70,16 +71,21 @@ After making sure you have defined `HYPRLAND_HEADERS` (you might need to do this
 you open a new terminal* if you don't put it in your `.bashrc` or `.zshrc` or whatever), the
 steps to build are simple
 
-### Manual way of doing things
+### Manually
 - `make`: This will build the `PLUGIN_NAME.so` file.
 - `hyprctl plugin unload $PWD/PLUGIN_NAME.so`: If you have an old version loaded, unload it
 - `hyprctl plugin load $PWD/PLUGIN_NAME.so`: Load the plugin
 
-### The `hyprload` way
+Do note that if you only load/unload from the same path, Hyprland can ignore your changes.
+
+### Using `hyprload`
 This works rather well in nested Hyprland sessions, since `hyprload` keeps sessions separate.
 - `make install`: This will build and copy the plugin to the `hyprload` plugin directory.
 - Reload `hyprload` for the changes to take effect
 
+This doesn't have the issue of ignoring changes, because of how `hyprload` handles its loaded
+plugins.
+
 ### Nested Hyprland
 Developing a plugin may be tough. You might crash Hyprland a couple times. For this reason,
 it's a good idea to develop them in a nested Hyprland session. If you run `Hyprland` from an