update turtle graphics protocol doc

turtle-graphics.md

@@ -29,7 +29,7 @@ Turtle graphics describe the movements and drawing behaviours of screen, robot,
   - "Lowers" the turtle's pen, starting it drawing a path.
 * `pencolor`, red: number, green: number, blue: number, alpha: number, OR: color: string
   - Sets the turtle's pen's color to the specified RGBA color.
-* `pendwidth`, width: number
+* `penwidth`, width: number
   - Sets the width of the turtle's pen, in pixels (or some other metric).
 * `home`, no arguments
   - Sends the turtle back to its starting point, with a heading of 0.
@@ -41,6 +41,8 @@ Turtle graphics describe the movements and drawing behaviours of screen, robot,
   - Shows the turtle.
 * `hide`, no arguments
   - Hides the turtle.
+* `loadstate`, x: number, y: number, heading: number, pendown: boolean, width: number, color: string OR r: number, g: number, b: number, a: number
+  - Loads a turtle state.
 * `clear`, no arguments
   - Erases any paths drawn and sets the background color to the default.
 * `background`, red: number, green: number, blue: number, alpha: number
@@ -61,3 +63,12 @@ These are fire-off commands.
 Errors should be _reported_ to `stderr` or equivalent.
 But Ludus sending things to its output streams should only cause Ludus panics when there's an issue in Ludus.
 
+**Colors aren't always RGBA.**
+For pen-and-paper turtles, we don't have RGBA colors.
+Colors should also be specifiable with strings corresponding to CSS basic colors: black, silver, gray, white, maroon, red, purple, fuchsia, green, lime, olive, yellow, navy, blue, teal, and aqua.
+
+**Turtles should maybe communicate states.** 
+Ludus should have access to turtle states.
+This is important for push/pop situations that we use for L-systems.
+There are two ways to do this: Ludus does its own bookkeeping for turtle states, or it has a way to get the state from a turtle.
+