i thiiiiink this is better?

.vscode/launch.json

@@ -10,9 +10,10 @@
       "request": "launch",
       "program": "${workspaceFolder}/hancho.py",
       "cwd": "${workspaceFolder}/tutorial",
-      "args": ["tut16.hancho"],
+      "args": ["-f", "build.hancho"],
       "console": "integratedTerminal",
       "justMyCode": false,
+      "preLaunchTask": "Wipe build",
     },
   ]
 }

.vscode/tasks.json

@@ -13,6 +13,11 @@
         "kind": "build",
         "isDefault": true
       }
+    },
+    {
+      "label": "Wipe build",
+      "type": "shell",
+      "command": "rm -rf build",
     }
   ]
 }

docs/tutorial/tut10.md

@@ -27,13 +27,13 @@ evaluated immediately. They do have some drawbacks, however:
 
 - Hancho templates can _only_ refer to fields in a ```Config``` object.
   - If you want to use ```print()``` in a template, you have to pass it in via ```Config(print = print)```.
-- List comprehensions usually won't work right unless the left-hand side is strictly of the form ```[x for x in...``` 
+- List comprehensions usually won't work right unless the left-hand side is strictly of the form ```[x for x in...```.
   - TL;DR: Python3 wraps list comprehensions in a scope that prevents additional ```Config``` field references and template expansions in the ```[x for x in...``` part.
   - This is a limitation deep inside the Python3 interpreter that has no good workaround.
 
 And some plus sides that f-strings don't have:
 - Templates aren't evaluated until immediately before a task runs, which allows them to include expressions that we may not know the value of beforehand
-  - For example, the name of a temporary file generated by another task. 
+  - For example, the name of a temporary file generated by another task.
 - Hancho templates that refer to ```list```s will get flattened out and joined with spaces
   - Expanding ```"{foo}"``` with ```foo = ["Hello", "Hancho", "World"]``` will produce ```"Hello Hancho World"```
   - Expanding ```"{foo}"``` with ```foo = [[["nesting"]], ["levels"], "don't", [[[[[["matter"]]]]]]]``` will produce ```"nesting levels don't matter"```
@@ -52,7 +52,7 @@ The ```description``` and ```command``` fields of our compile tasks are now iden
 
 https://github.com/aappleby/hancho/blob/b895dd1792e4bcaa47c670fc0c139278e77a1b4f/tutorial/tut11.hancho#L13-L16
 
-Extending config objects works like prototypal inheritance in Javascript - if you refer to ```config.foo``` and ```config``` doesn't have its own ```foo```, it'll look for ```foo``` in the parent object and so on - up until it hits ```global_config```, which we haven't talked about yet.
+Extending config objects works like prototypal inheritance in Javascript - if you refer to ```config.foo``` and ```config``` doesn't have its own ```foo```, it'll look for ```foo``` in the parent object and so on - up until it hits ```app.global_config```, which we haven't talked about yet.
 
 That removes another two lines of task-independent stuff from our compile task: