more typos and spelling.

content/posts/clirenaissance/index.md

@@ -100,7 +100,7 @@ The majority of the foundational CLI tools on a Linux pc, even one installed yes
 
 ## Ok, so?
 
-Now, theres nothing wrong with this.
+Now, there's nothing wrong with this.
 The tools still work fine, but in the half-century since they were first written,
 terminals and the broader Linux ecosystem have all changed.
 Terminals now have capacity to display more colours, Unicode symbols, and even inline images.
@@ -110,7 +110,7 @@ whereas in the past, terminals were the only way one interacted with the compute
 
 Perhaps more importantly, our knowledge has expanded:
 our knowledge of user interfaces,
-of what works and what doesnt,
+of what works and what doesn't,
 of what usecases are common and what usecases are niche,
 the way that error messages can teach,
 the value of a good out of the box experience,
@@ -119,9 +119,9 @@ and the value of documentation that is easy to find and digest.
 These changes to the environment surrounding CLI apps in recent years have
 led to a resurgence in development of command line utilities.
 Instead of just developing completely new tools or cloning old tools,
-Ive noticed that people are rethinking and reinventing tools that have existed since the early days of Unix.
+I've noticed that people are rethinking and reinventing tools that have existed since the early days of Unix.
 
-This isnt just some compulsive need to rewrite every tool out there in your favorite language.
+This isn't just some compulsive need to rewrite every tool out there in your favorite language.
 People are looking at the problem these tools set out to solve,
 and coming up with their own solutions to them,
 exploring the space of possible solutions and taking new approaches.
@@ -172,12 +172,12 @@ It has a few colours, shows everything the bash prompt does, and additionally sh
 Text editors are another great example of the evolution of out of the box defaults.
 Vim and Neovim both improved on their predecessors,
 but much of that improvement is locked behind extremely complex configuration experiences and plugins.
-Heres four different terminal text editors with no configuration applied:
+Here's four different terminal text editors with no configuration applied:
 
 ![vi, vim, neovim, and helix editors in their default
 configuration](editors.png)
 
-Vi, (top left) is our baseline, and, as far as I can tell, doesnt actually
+Vi, (top left) is our baseline, and, as far as I can tell, doesn't actually
 support much for configuration. What you see out of the box is more or less
 whats there.
 
@@ -192,12 +192,12 @@ In order to take advantage of the LSP and Treesitter support, you have to instal
 which means learning a Nvim package manager, learning how to configure LSPs,
 and configuring a new LSP for every language you want to use it with
 (or finding out about Mason and being OK with having multiple levels of package management in your Nvim install alone).
-Dont get me wrong: Neovim is a great editor once you get over the hump.
+Don't get me wrong: Neovim is a great editor once you get over the hump.
 I still use it as my daily driver, but so much of its functionality is simply hidden.
 
 Then we have the Helix (bottom right) editor.
 Slightly glaring default colour scheme aside, everything is just *there*.
-Helix doesnt have plugin support [yet](https://github.com/helix-editor/helix/discussions/3806),
+Helix doesn't have plugin support [yet](https://github.com/helix-editor/helix/discussions/3806),
 but it has so much stuff in core that,
 looking through my neovim plugins,
 pretty much all of them are in the core editor!
@@ -216,19 +216,19 @@ but its an extremely usable IDE out of the box thanks to having all of its featu
 
 In my nvim config, I use [which-key](https://github.com/folke/which-key.nvim),
 a plugin that displays available keybindings as you type.
-Ive been using vim for almost a decade, including a long time without which-key,
+I've been using vim for almost a decade, including a long time without which-key,
 so its not like I never learned the keybindings, but I still find which-key useful.
 Why is that, you may ask?
-Well, because even though I use (n)vim every day, I dont use all the keybindings every day.
+Well, because even though I use (n)vim every day, I don't use all the keybindings every day.
 I might go months between using, for example, `dap` (delete current paragraph), or `C-w x` (swap current window for next).
 Naturally, when you go months without using certain parts of a program, you tend to forget they exist.
-Which-key solves that handily, by offering quick, non-intrusive reminders of what is availible.
-Heres what my which-key config looks like:
+Which-key solves that handily, by offering quick, non-intrusive reminders of what is available.
+Here's what my which-key config looks like:
 
 ![Which-key.nvim](nvim_which_key.png)
 
 Now, which-key and its like have been around for a while,
-but other TUI programs have integreated contextual hints without the need for a plugin.
+but other TUI programs have integrated contextual hints without the need for a plugin.
 The two that I am aware of are zellij and helix.
 
 ![Helix's contextual hint](helix_contextual_hint.png)
@@ -237,7 +237,7 @@ Helix both has autocompletion for its built in command line and a contextual hin
 This drastically helps both new and experienced users learn and remember keybinds without making the editor any less powerful.
 
 Zellij has a bottom bar displaying keybindings available in the current mode.
-This has proven invaluable for me, as I dont use a terminal multiplexer much
+This has proven invaluable for me, as I don't use a terminal multiplexer much
 (On GUI systems, I use the window manager for managing multiple terminals), and as such tend to forget the keybinds.
 
 <!-- look at zellij and helix and their built in keymap cheatsheets-->
@@ -247,17 +247,17 @@ This has proven invaluable for me, as I dont use a terminal multiplexer much
 <!-- look at sd, rg, and fd-->
 Where possible, documentation should not even be required for the most common use cases.
 Whenever I want to use `find`, I almost always have to first look at the man page,
-as I dont use it quite often enough to memorize it.
-But thats totally unneeded! 90% of my uses of `find` take the form of `find ./ -name "*foo*"`.
+as I don't use it quite often enough to memorize it.
+But that's totally unneeded! 90% of my uses of `find` take the form of `find ./ -name "*foo*"`.
 With [fd](https://github.com/sharkdp/fd), the exact same invocation is a simple `fd foo`, dead simple, no man page needed.
-Of course, 10% of the time im doing something else and have to look at the manual even with fd,
+Of course, 10% of the time I'm doing something else and have to look at the manual even with fd,
 but the point is that manuals are for when you want to do something with the tool that is not the most common usecase.
 
 There are many other examples as well. How many of your grep invocations are in the form of `grep -R 'foo' ./`?
 Most of mine are. [Ripgrep](https://github.com/BurntSushi/ripgrep) shortens that to `rg foo`
 while still having all the power of grep when I need it, and it is faster to boot!
 
-This isnt to say that tools should 'dumb themselves down' or hobble themselves to make them easier to use.
+This isn't to say that tools should 'dumb themselves down' or hobble themselves to make them easier to use.
 However they should keep in mind the most common usecase that their tool is likely to be used in,
 and streamline that usecase.
 
@@ -279,7 +279,7 @@ and file modification time laziness
 
 These features are *good* features when make is being used as a build system,
 but another major use of make that has emerged has been as a way to run common tasks.
-so alongside `make build` to buld your program, you would have `make bootstrap`, `make test`, `make config`, etc.
+So alongside `make build` to build your program, you would have `make bootstrap`, `make test`, `make config`, etc.
 This is where the design decisions behind make the build system start to hinder make the task runner,
 making one learn about make the build system in order to work around those features to use make the task runner.
 However, make cant drop these features, both because projects still actively use make as a build system,