rework around cactus-ssg

5 files changed, 18 insertions, 18 deletions

diff --git a/_posts/2018-06-23-slicing-images-gimp-python.md b/_posts/2018-06-23-slicing-images-gimp-python.md
index 1ad3514..83264b8 100644
--- a/_posts/2018-06-23-slicing-images-gimp-python.md
+++ b/_posts/2018-06-23-slicing-images-gimp-python.md
@@ -70,7 +70,7 @@ def crop(image, x, width, y, height):
 ```
 
 The next step is to figure out the filename for this specific tile; here we're getting an index back from the offsets and width and height.
-```python 
+```python
     x_idx = x / width + 1
     y_idx = y / width + 1
     filename = pdb.gimp_image_get_filename(image)
diff --git a/_posts/2020-06-26-police-scanner-setup.md b/_posts/2020-06-26-police-scanner-setup.md
index 3f51871..b8c621b 100644
--- a/_posts/2020-06-26-police-scanner-setup.md
+++ b/_posts/2020-06-26-police-scanner-setup.md
@@ -79,7 +79,7 @@ of audio input and output devices. check the number in the input list that goes
 with CABLE Output - for me it's 3. pull up notepad and make a new file. since
 my input was number 3, i'm typing
 
-```
+```bat
 DSDPlus.exe -i3M
 ```
 
@@ -89,7 +89,7 @@ is set to "All Files", and name the file `run.bat`. close dsd+, go to that
 folder, and open that `run.bat` file you just created. it should pull up dsd+
 and if you're lucky it'll print
 
-```
+```text
 audio input device #3 (CABLE Output (VB-Audio Virtual ) initialized
 ```
 
@@ -194,7 +194,7 @@ you'll need to set DSD+ to output to "CABLE-A Input" like how you set it to
 input from "CABLE Output" - Cable A is the fourth output in DSD+, so my run.bat
 now looks like this:
 
-```
+```bat
 DSDPlus.exe -i3M -o4
 ```
 
diff --git a/_posts/2020-09-16-survey-of-rust-embeddable-scripting-languages.md b/_posts/2020-09-16-survey-of-rust-embeddable-scripting-languages.md
index 27df9f3..c2214c0 100644
--- a/_posts/2020-09-16-survey-of-rust-embeddable-scripting-languages.md
+++ b/_posts/2020-09-16-survey-of-rust-embeddable-scripting-languages.md
@@ -275,7 +275,7 @@ As you may notice, we have to put the number into a string before we can add it
 This is because all values in Duckscript are strings.
 
 Well, now that we've got all the code to pass in variables and run it, let's write our event handler script:
-```
+```duckscript
 if eq ${event.type} "number"
     echo "number!" ${event.value}
 else
@@ -332,7 +332,7 @@ impl ScriptHost for RhaiScriptHost {
 That's all of it.
 That's the whole damn thing.
 Our script is pretty darn straightforward, too, unsurprisingly:
-```
+```rhai
 fn handle_event(data) {
     if type_of(data) == "i64" {
        print("number! " + data);
@@ -392,7 +392,7 @@ impl ScriptHost for DyonScriptHost {
 ```
 
 Our script is likewise pretty straightforward:
-```
+```dyon
 fn handle_event(data) {
     if typeof(data) == "number" {
        println("number! " + str(data))
@@ -472,7 +472,7 @@ impl ScriptHost for KetosScriptHost {
 ```
 
 Our script itself is... definitely Lisp-y.
-```
+```ketos
 (define (handle-event event)
     (do
         (println "~a ~a" (type-of event) event)
@@ -529,7 +529,7 @@ impl ScriptHost for RuneScriptHost {
 
 Again, we have zero glue required for our `print_fancy` function, which is nice.
 Our script looks pretty decent too:
-```
+```rune
 fn handle_event(event) {
     match event {
         n if n is int => println(`Number! {n}`),
@@ -622,7 +622,7 @@ impl ScriptHost for RuwrenScriptHost {
 ```
 
 And our test script in Wren looks nice:
-```
+```wren
 import "demo" for Demo
 class EventHandler {
     static handleEvent(data) {
diff --git a/_posts/2020-10-13-crowbar-2-simplifying-c-type-names.md b/_posts/2020-10-13-crowbar-2-simplifying-c-type-names.md
index 8a63947..9a825e3 100644
--- a/_posts/2020-10-13-crowbar-2-simplifying-c-type-names.md
+++ b/_posts/2020-10-13-crowbar-2-simplifying-c-type-names.md
@@ -2,7 +2,7 @@
 title: "Crowbar: Simplifying C's type names"
 ---
 
-(Previously in Crowbar: [Defining a good C replacement]({% link _posts/2020-09-28-crowbar-1-defining-a-c-replacement.md %}).)
+(Previously in Crowbar: [Defining a good C replacement](/2020/09/28/crowbar-1-defining-a-c-replacement.md).)
 
 I've been working intermittently on drawing up a specification for [Crowbar](https://sr.ht/~boringcactus/crowbar-lang/), a C replacement aiming to be both simpler and safer.
 I'm still nowhere near done, but I'm proud of the concept I've reached for type names, and I want to explain it in depth here.
@@ -21,7 +21,7 @@ Ideally, we can preserve the syntax as is for simple cases, while cutting down o
 
 As of right now, the Crowbar specification gives the syntax as a [parsing expression grammar](https://en.wikipedia.org/wiki/Parsing_expression_grammar), which I'll give an excerpt from here:
 
-```
+```peg
 Type      ← 'const' BasicType /
             BasicType '*' /
             BasicType '[' Expression ']' /
@@ -50,7 +50,7 @@ char *str[10];
 Evidently this means "str is an array 10 of pointers to char".
 How would we express that in Crowbar (as it hypothetically exists so far)?
 
-```
+```crowbar
 (char *)[10] str;
 ```
 
@@ -58,7 +58,7 @@ Now that's more like it.
 We can look at it and tell right away that the array is the outermost piece and so `str` is an array.
 In C, I'm not sure how we'd express a pointer-to-arrays-of-10-chars, but in Crowbar it's also straightforward:
 
-```
+```crowbar
 (char[10])* str;
 ```
 
@@ -72,7 +72,7 @@ char *(*fp)( int, float *);
 which supposedly means "fp is a pointer to a function passing an int and a pointer to float returning a pointer to a char".
 That's not extremely dreadful, merely somewhat off-putting, but let's see how it looks in Crowbar.
 
-```
+```crowbar
 ((char *) function(int, (float *),)* fp;
 ```
 
@@ -93,7 +93,7 @@ That fractal mess is "a function passing an int and a pointer to a function pass
 My eyes glaze over reading that description even more than they do reading the original C.
 Can we make this not look awful?
 
-```
+```crowbar
 ((void function(int,))*) signal(int, ((void function(int,))*),);
 ```
 
@@ -114,7 +114,7 @@ int * const const_pointer; // can never do const_pointer = &x;
 You have to remember which is which.
 And why memorize when you can read?
 
-```
+```crowbar
 (const int)* points_to_const;
 const (int *) const_pointer;
 ```
diff --git a/_posts/2020-10-19-crowbar-3-this-is-tough.md b/_posts/2020-10-19-crowbar-3-this-is-tough.md
index 85dd7bd..a499bc1 100644
--- a/_posts/2020-10-19-crowbar-3-this-is-tough.md
+++ b/_posts/2020-10-19-crowbar-3-this-is-tough.md
@@ -2,7 +2,7 @@
 title: "Crowbar: Turns out, language development is hard"
 ---
 
-(Previously in Crowbar: [Defining a good C replacement]({% link _posts/2020-09-28-crowbar-1-defining-a-c-replacement.md %}), [Simplifying C's type names]({% link _posts/2020-10-13-crowbar-2-simplifying-c-type-names.md %}))
+(Previously in Crowbar: [Defining a good C replacement](/2020/09/28/crowbar-1-defining-a-c-replacement.md), [Simplifying C's type names](/2020/10/13/crowbar-2-simplifying-c-type-names.md))
 
 Originally, I hadn't decided whether Crowbar should be designed with an eye towards compiling to C or with an eye towards compiling directly.
 Compiling to C massively cuts down the scope of Crowbar as a project, but compiling directly gives me more comprehensive control over what all happens.