Switch over to a nicer formatter

.vscode/settings.json

@@ -5,8 +5,8 @@
     "stylelint.validate": ["css", "astro"],
     "eslint.validate": ["typescript", "astro"],
     "editor.formatOnSave": true,
-    "editor.defaultFormatter": "esbenp.prettier-vscode",
+    "editor.defaultFormatter": "dprint.dprint",
     "[astro]": {
-        "editor.defaultFormatter": "astro-build.astro-vscode"
+        "editor.defaultFormatter": "dprint.dprint"
     }
 }

astro.config.ts

@@ -2,8 +2,8 @@ import { defineConfig } from "astro/config";
 
 import mdx from "@astrojs/mdx";
 import sitemap from "@astrojs/sitemap";
-import { visit } from "unist-util-visit";
 import GithubSlugger from "github-slugger";
+import { visit } from "unist-util-visit";
 
 // https://astro.build/config
 export default defineConfig({

dprint.json

@@ -0,0 +1,10 @@
+{
+    "excludes": ["**/node_modules", "**/*-lock.json"],
+    "plugins": [
+        "https://plugins.dprint.dev/typescript-0.91.6.wasm",
+        "https://plugins.dprint.dev/json-0.19.3.wasm",
+        "https://plugins.dprint.dev/markdown-0.17.6.wasm",
+        "https://plugins.dprint.dev/g-plane/markup_fmt-v0.12.0.wasm"
+    ],
+    "indentWidth": 4
+}

package.json

@@ -21,13 +21,12 @@
     },
     "devDependencies": {
         "@typescript-eslint/parser": "^8.2.0",
+        "dprint": "^0.47.2",
         "eslint": "^8.57.0",
         "eslint-plugin-astro": "^1.2.3",
         "eslint-plugin-deprecation": "^3.0.0",
         "eslint-plugin-jsx-a11y": "^6.8.0",
         "postcss-html": "^1.5.0",
-        "prettier": "^3.1.1",
-        "prettier-plugin-astro": "^0.14.1",
         "stylelint": "^16.1.0",
         "stylelint-config-html": "^1.1.0",
         "stylelint-config-standard": "^36.0.0"

src/content/journal/an-outside-view-of-programming.md

@@ -6,8 +6,8 @@ summary: "Being a programmer, it's hard to remember what drew me"
 
 I absolutely love programming. Recently, I've been thinking about how non-programmers view programmers, specifically in the context of what programmer-specific content would a non-programmer appreciate? This is part of a larger rethinking of myself. So here's my thoughts:
 
--   Decompiling is interesting and fun to do, but runs into some legal barriers (as part of software contracts). Supposedly the DMCA (see what I was talking about yesterday??) sets aside a specific exclusion for interop purposes. Think liveoverflow.
--   Actually making a software project. I'm not sure this is entertaining for non-software folks, unless explained well. Explaining is hard!
--   Reacting to software news. This isn't entertaining to non-programmers, I think. Think Primeagen, fireship.
+- Decompiling is interesting and fun to do, but runs into some legal barriers (as part of software contracts). Supposedly the DMCA (see what I was talking about yesterday??) sets aside a specific exclusion for interop purposes. Think liveoverflow.
+- Actually making a software project. I'm not sure this is entertaining for non-software folks, unless explained well. Explaining is hard!
+- Reacting to software news. This isn't entertaining to non-programmers, I think. Think Primeagen, fireship.
 
 Looking for analogues to software engineering, I find stuff like Practical Engineering or Veritasium, who produce high quality videos explaining larger systems. I think that might be the best approach listed here.

src/content/journal/decoding-azw3f-azw3r.md

@@ -9,18 +9,18 @@ Yes, I know KFX is a thing nowadays and AZW3 is dumb and old. But I have AZW3 bo
 
 Anyways from the start, I'm assuming this is a TLV-style format. And looking at it more, it does seem that way for arrays at least:
 
--   `FE` is the tag for an array
--   `1` means the name is zero size, otherwise continue
--   big endian `u16` for name size
--   followed by size bytes which is the array's name
--   this is followed by any number of values, ending with a `FF` tag
+- `FE` is the tag for an array
+- `1` means the name is zero size, otherwise continue
+- big endian `u16` for name size
+- followed by size bytes which is the array's name
+- this is followed by any number of values, ending with a `FF` tag
 
 String values seem to be represented as such:
 
--   `03` as a tag
--   `1` means stop and this is zero length, otherwise continue
--   big endian `u16` for size
--   followed by size bytes which is that string's contents
+- `03` as a tag
+- `1` means stop and this is zero length, otherwise continue
+- big endian `u16` for size
+- followed by size bytes which is that string's contents
 
 The overall file seems to consistently start with:
 
@@ -32,28 +32,28 @@ Followed by a big endian `u32` which is the number of values.
 
 Smaller integer values seem to be represented as such:
 
--   `01` as a tag
--   big endian `u32`
+- `01` as a tag
+- big endian `u32`
 
 Integer values seem to be as such:
 
--   `02` as a tag
--   big endian `u64`
+- `02` as a tag
+- big endian `u64`
 
 I'm pretty sure these are floats? (based on looking things up etc.)
 
--   `04` as tag
--   `f64`
+- `04` as tag
+- `f64`
 
 When making a parser for this, I encounted a tag `0`:
 
--   `00` as tag
--   presumably `00` for false and `01` for true
+- `00` as tag
+- presumably `00` for false and `01` for true
 
 I also found `7`:
 
--   `07` as a tag
--   single byte
+- `07` as a tag
+- single byte
 
 Here's what an azw3r file looks like when parsed:
 

src/content/journal/error-resilient-peg-parsing.md

@@ -11,7 +11,7 @@ However, PEG parsing relies on parsing failures to parse things. I don't immedia
 
 I don't have a solution. Here's some ideas I've been considering:
 
-1.  Parse without error resilience, then if all paths fail then take the one that went the "furthest" with error resilience. If there's a tie then probably just go with the first parse option. This seems to be a good idea for prefix-related mistakes (so like, `def () -> None print("haiii")` or `[3, 4 a = 4`), especially when combined with swift-syntax style token precedence (e.g. you cannot parse past punctuation looking for an identifier). But this doesn't seem like a very good idea for suffix-related mistakes (`b = 5, 6]`). I think this might be an acceptable tradeoff for programming where we mostly write left-to-right.
-2.  Just skip the current token instead.
+1. Parse without error resilience, then if all paths fail then take the one that went the "furthest" with error resilience. If there's a tie then probably just go with the first parse option. This seems to be a good idea for prefix-related mistakes (so like, `def () -> None print("haiii")` or `[3, 4 a = 4`), especially when combined with swift-syntax style token precedence (e.g. you cannot parse past punctuation looking for an identifier). But this doesn't seem like a very good idea for suffix-related mistakes (`b = 5, 6]`). I think this might be an acceptable tradeoff for programming where we mostly write left-to-right.
+2. Just skip the current token instead.
 
 I think 1. is an acceptable approach for my application. But I haven't implemented it so maybe I'll come back here talking about how it's a bad idea.

src/content/journal/failing-loudly.md

@@ -8,8 +8,8 @@ I really don't like JavaScript's tendency to fail quietly. I understand the rati
 
 Let's compare two possible approaches for handling external data:
 
--   throwing it into an unstructured blob and going through that
--   converting it via a schema
+- throwing it into an unstructured blob and going through that
+- converting it via a schema
 
 JavaScript seems to go with the first. It sucks. Special syntax for property access, conveniences for unexpected data, type coersion, etc.