diff --git a/README.md b/README.md
index 208e82c..5f01af3 100644
--- a/README.md
+++ b/README.md
@@ -1,8 +1,8 @@
 # ISSUES
-No matter what I do it says that there are 2666 allocations or something. This
-is concerning.
+When a memory bug is detected in one of the treads it won't report a non-zero
+exit code while running the tests.
 
-# A collection of libraries inspired by zig
+# A collection of libraries inspired by zig, and other stuff.
 
 I like zig, but I really like writing C. I am starting with implementing
 different allocator types. I don't know how the other parts of the library will
@@ -11,24 +11,23 @@ fit in, but they will certainly use the allocators.
 I want a series of standard collection types with nice interfaces. ArrayLists,
 LinkedLists, value-based HashMaps, reference-based HashMaps.
 
-I also want to provide snippets for generating safe bit-flags and tagged
-unions. This will be done with the X-macro pattern. As well as snippets I want
-some sort of explanation of why the snippets are made the way they are, and
-what value it provides to follow those patterns.
+I also want to provide template header files that use the X-macro pattern so
+that users can easily make tagged unions, option types, automatic bit-flags,
+and maybe even an ECS inspierd struct filled with optional fields.
 
-I probably want a ui library. It too wil rely on a graphical drawing interface.
-It will be a little different though. It is inspired from my experience with
-using raygui. instead of making some sort of layout engine, I will provide a
-set of useful functions to manipulate rectangles. I think this produces
-programs that are easier to reason about, while still reducing needless
-duplication of code. The workflow relies heavily on function-static variables,
-which are a c superpower in this scenario. You will essentially start with some
-'fixed' rectangle (probably derived from the window size) and then perform
-splitting operations on that rectangle. Even a dynamic split that creates a
-draggable border, updating the local function-static variable (which is a
-normalized float) to let you resize sections. Also, the interface will be like
-immediate mode guis, with one exception from the way raygui works. The drawing
-operations are deferred, and called in the reverse order. This way the first
-gui function that captrues input can signal to the other function that input is
-captured, and the drawing of the gui elements can reflect the priority of the
-gui functions. Overlapping gui elements in raygui is the main painpoint imo.
+I probably want a ui library. It will rely on a graphical drawing interface. It
+will be a little different though. It is inspired from my experience with using
+raygui. instead of making some sort of layout engine, I will provide a set of
+useful functions to manipulate rectangles. I think this produces programs that
+are easier to reason about, while still reducing needless duplication of code.
+The workflow relies heavily on function-static variables, which are a c
+superpower in this scenario. You will essentially start with some 'fixed'
+rectangle (probably derived from the window size) and then perform splitting
+operations on that rectangle. Even a dynamic split that creates a draggable
+border, updating the local function-static variable (which is a normalized
+float) to let you resize sections. Also, the interface will be like immediate
+mode guis, with one exception from the way raygui works. The drawing operations
+are deferred, and called in the reverse order. This way the first gui function
+that captrues input can signal to the other function that input is captured,
+and the drawing of the gui elements can reflect the priority of the gui
+functions. Overlapping gui elements in raygui is the main painpoint imo.