proofreading.

content/posts/clirenaissance/index.md

@@ -26,7 +26,7 @@ vim,https://www.vim.org/,1991,c
 midnight commander,,1994,c
 ssh,,1995,c
 curl,https://github.com/curl/curl,1996,c
-fish,https://fishshell.com/,2005,c/rust
+fish,https://fishshell.com/,2005,c (currently being rewritten in rust)
 fossil,https://fossil-scm.org/home/doc/trunk/www/index.wiki,2006,c
 tmux,https://github.com/tmux/tmux,2007,c
 git,https://git-scm.com/,2008,c
@@ -78,34 +78,36 @@ xsel -bi
 ls specifically can trace its history to 1961 
 -->
 
-Take a look at this [table](#appendix-the-tools) at the bottom of the page. Ill
-wait. Notice the relative scarcity between ~1995 and ~2015? Id like to talk
-about a trend Ive seen these past few years, where people are rewriting and
-rethinking staples of the CLI, why I think this trend is a good thing, and why I
-think this trend might be happening.
+Take a look at this [table](#appendix-the-tools) at the bottom of the page.
+Ill wait.
+Notice the relative scarcity between ~1995 and ~2015?
+Id like to talk about a trend Ive seen these past few years,
+where people are rewriting and rethinking staples of the command line interface,
+why I think this trend might be happening,
+and why I think this trend is a good thing.
 
 ## History
 
-The terminal has been a staple of computer user interfaces since before computer monitors were available,
+The terminal and the command line interface have been staples of computer user interfaces before computer monitors were even available,
 with some of the first computers offering an interactive mode in the late 1950's.
-The 'modern' Linux terminal traces its linage to the very first version of Unix, in 1971.
+The recognizable Linux terminal traces its linage to the very first version of Unix in 1971.
 Many utilities that a Linux user interacts with every day,
-commands like `rm`, `cat`, `cd`, `cp`, `man` and a host of other core commands trace their initial versions to this first version of Unix.
-Other tools are a bit newer, such as `sed` (1974), `diff` (1974) `bc` (1975), `make` (1976) or `vi` (1976).
-There were a few more tools introduced in the 90's, such as `vim` (1991) and `ssh`, (1995), but you get the picture.
+commands like `rm`, `cat`, `cd`, `cp`, `man`, and a host of other core commands trace their initial versions to this first version of Unix.
+Other tools are a bit newer, such as `sed` (1974), `diff` (1974) `bc` (1975), `make` (1976), or `vi` (1976).
+There were a few more tools introduced in the 90's, such as `vim` (1991) and `ssh` (1995), but you get the picture.
 The majority of the foundational CLI tools on a Linux pc, even one installed yesterday, are older than Linux itself is.
 
 ## Ok, so?
 
-Now, theres nothing wrong with this, the tools work fine still, but,
-in the half-century since they were first written,
-Terminals and the broader Linux ecosystem have all changed.
+Now, theres 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.
 Terminal programs now coexist with graphical user interfaces,
 and only a small subset of computer users even know they exist,
-wheras in the past, terminals were the only way one interacted with the computer.
+whereas in the past, terminals were the only way one interacted with the computer.
 
-Additionally, and perhaps more importantly, our knowledge has expanded,
+Perhaps more importantly, our knowledge has expanded:
 our knowledge of user interfaces,
 of what works and what doesnt,
 of what usecases are common and what usecases are niche,
@@ -113,18 +115,25 @@ the way that error messages can teach,
 the value of a good out of the box experience,
 and the value of documentation that is easy to find and digest.
 
-## Exploration of the solution space
-
-These changes to the environment surrounding CLI apps has in recent years,
+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,
+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.
 
-<!--TODO: add more here-->
+This isnt 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.
+
+Its this exploration of the solution space that id like to take a look at:
+the ways that tools are changing,
+why people are changing them,
+and what kicked off this phenomenon.
 
 ## The lessons learned from the past
 
-A large amount of the innovation in the area, I think, can be attributed to lessons that have been learned in 50 years of using software;
+A large amount of the innovation in the area, I think,
+can be attributed to lessons that have been learned in 50 years of using software:
 sharp edges we have repeatedly cut ourselves on,
 unintuitive interfaces that repeatedly trip us up,
 and growing frustration at the limitations that maintaining decades of backwards compatibility imposes on our tools.
@@ -145,12 +154,12 @@ One of the earliest examples of this principle may be the fish shell.
 Both zsh and fish have powerful prompt and autocompletion engines,
 but zsh requires you to setup a custom prompt and enable completions in order to use the features that set it apart from the competition.
 With no config file, zsh is no better than bash.
-When starting fish for the first time however,
+When starting fish for the first time, however,
 its powerful autocompletion and information rich prompt are front and center with no configuration required.
 Of course, fish still has the same level of configurability as zsh, it just also has sensible defaults.
 
 To demonstrate my point, this is the default prompt for zsh with no configuration.
-It *only* shows the hostname, none of the advanced featurs you can get out of a zsh prompt even without plugins.
+It *only* shows the hostname, none of the advanced features you can get out of a zsh prompt even without plugins.
 ![zsh prompt, only shows hostname](zsh_prompt.png)
 Here is bash's prompt.
 It actually gives more info than zsh's, even though zsh can do more when properly configured.
@@ -172,25 +181,29 @@ support much for configuration. What you see out of the box is more or less
 whats there.
 
 Vim (top right) greatly improved on Vi, adding things such as syntax highlighting, line numbers, spellchecking, split windows, folding, and even basic autocompletion.
-However, everything but syntax highligting is either extremely clunky or outright disabled without configuration.
+However, everything but syntax highlighting is either extremely clunky or outright disabled without configuration.
 (for example, the earliest things I did when I first made a `.vimrc` was to enable indent folding,
 make some better keybinds for navigating windows, and adding a line number ruler to the side)
 
-Neovim (bottom left) further improved on Vim, adding support for Treesitter and the Language Server Protocoll, but the out of the box experience is the *exact* same as vim!
+Neovim (bottom left) further improved on Vim, adding support for Treesitter and the Language Server Protocol, 
+but the out of the box experience is the *exact* same as vim!
 In order to take advantage of the LSP and Treesitter support, you have to install plugins,
-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, I still use it as my daily driver, but so much of its functionality is simply hidden.
+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.
+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. Colour scheme aside, everything is just there.
+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),
 but it has so much stuff in core that,
 looking through my neovim plugins,
 pretty much all of them are in the core editor!
-(ironically, the one feature that I feel helix is missing, [folding](https://github.com/helix-editor/helix/issues/1840),
-is a core part of neovim, albiet one that requires some configuration to get good use out of).
+(Ironically, the one feature that I feel helix is missing, [folding](https://github.com/helix-editor/helix/issues/1840),
+is a core part of neovim, albeit one that requires some configuration to get good use out of).
 Helix does have a config file where you can change a huge amount of settings,
-but its an extremely usable IDE out of the box, thanks to having all of its features enabled by default.
+but its an extremely usable IDE out of the box thanks to having all of its features enabled by default.
 
 ### Friendly error messages
 
@@ -250,7 +263,7 @@ available, wikipedia otherwise, and sorting is by year first, then alphabetical.
 |midnight commander|1994|c|
 |ssh|1995|c|
 |[curl](https://github.com/curl/curl)|1996|c|
-|[fish](https://fishshell.com/)|2005|c/rust|
+|[fish](https://fishshell.com/)|2005|c (currently being rewritten in rust)|
 |[fossil](https://fossil-scm.org/home/doc/trunk/www/index.wiki)|2006|c|
 |[tmux](https://github.com/tmux/tmux)|2007|c|
 |[git](https://git-scm.com/)|2008|c|

content/posts/ferrisSweepKeyboard/index.md

@@ -6,35 +6,40 @@ draft = false
 image = "keyboard_with_case"
 +++
 
-Ive been using a split keyboard at home now for several years,
+Ive been using a split keyboard at home now for several years
 (specifically, the [UHKv2](https://ultimatehackingkeyboard.com/), though nowadays I probably would have gone for something ortholinear)
 and ive always wanted one for the office.
 The problem was, if I was going to get a new keyboard,
 I wanted it to be for both the office and travel,
 and most prebuilts around are not that portable.
 I also was not confident enough in my soldering skills to solder the SMT diodes found on many handbuilt designs out there.
-Eventually, though, I stumbled upon the github page for the [Ferris Sweep](https://github.com/davidphilipbarr/Sweep).
+Eventually though, I stumbled upon the github page for the [Ferris Sweep](https://github.com/davidphilipbarr/Sweep).
 
 ## The Basic Build
 
 The Sweep seemed simple enough that I could assemble it,
-and after doing some shopping around, I was able to source all the parts I needed for under $100.
+and after doing some shopping around,
+I was able to source all the parts I needed for under $100.
 I ordered the pcb from JLPCB and the parts from [Keebio](https://keeb.io/) and [Lowprob.ca](https://lowprokb.ca/),
 and started the long wait for it all to arrive.
 
-In the meantime, I researched what how to flash the [elite-pi](https://docs.keeb.io/elite-pi-guide)'s I had purchased with QMK.
-(normal elite-c's were out of stock, and I like the RP2040.)
-its a little bit different, but as long as you have used QMK before, it wasnt much extra to that.
+In the meantime, I researched how to flash the [elite-pi](https://docs.keeb.io/elite-pi-guide)'s I had purchased with QMK.
+(Normal elite-c's were out of stock, and I like the RP2040.)
+Its a little bit different, but as long as you have used QMK before, it isnt much extra.
 
-When the parts came, I socketed the microcontrollers, soldered the sockets to the pcbs,
-and finally soldered the switches in. (I used choc purpz, a bit of a leap of faith from my usual heavy tactile switches).
+When the parts came,
+I socketed the microcontrollers,
+soldered the sockets to the pcbs,
+and finally soldered the switches in.
+(I used choc purpz, a bit of a leap of faith from my usual heavy tactile switches).
 I did ruin one switch by letting a leg getting hot enough to melt the housing plastic,
-and desoldering it was unexpectedly difficult, but not every build can be mistake free, right?
+and desoldering it was unexpectedly difficult,
+but not every build can be mistake free, right?
 
 ![The finished keyboard](finished_keyboard.jpg)
 
 Flashing QMK was uneventful, working exactly as the [QMK docs](https://github.com/qmk/qmk_firmware/tree/master/keyboards/ferris/sweep) for the Ferris Sweep suggested.
-I would, however, recommend flashing the micros _before_ doing any soldering,
+I would, however, recommend flashing the micros *before* doing any soldering,
 I had to take my micros out of their sockets in order to access the boot buttons.
 (once the keyboard is assembled, there is a dedicated keycombo on most layouts to enter the bootloader,
 so you dont have to do this every time you reflash your keyboard)
@@ -52,7 +57,7 @@ I moved the numpad layer to my right hand side, swapping its position with the f
 I also put the meta key as a hold-mod on the lower pinky keys, as my window manager uses it for all its keybinds.
 
 The mod-tap home row layer changes actually feel really natural,
-and the extra space afforded by layers allows me to organize things in a more natural feeing way,
+and the extra space afforded by layers allows me to organize things in a more natural feeling way,
 such as putting the numbers in a numpad layout, rather than along the top.
 Im not quite happy with my modifiers being mod-taps on the bottom row,
 they can feel slightly awkward to reach,

content/posts/nushell.md

@@ -4,8 +4,8 @@ date = 2024-03-01T11:34:04-06:00
 +++
 
 Ive been experimenting with the tools I use on a regular basis lately -- switching
-up my shell, terminal multiplexer, and even trying out other editors. Today,
-Id like to focus on my experiments with my shell.
+up my shell, terminal multiplexer, and even trying out other editors.
+Today, Id like to focus on my experiments with my shell.
 
 ## My old setup