diff --git a/docs/Code_Overview.md b/docs/Code_Overview.md
index 6ee53fa4..c47d783c 100644
--- a/docs/Code_Overview.md
+++ b/docs/Code_Overview.md
@@ -68,10 +68,10 @@ function to be called at the requested clock time. Timer interrupts
 are initially handled in an architecture specific interrupt handler
 (eg, **src/avr/timer.c**) which calls sched_timer_dispatch() located
 in **src/sched.c**. The timer interrupt leads to execution of schedule
-timer functions. Timer functions always run with interrupts
-disabled. The timer functions should always complete within a few
-micro-seconds. At completion of the timer event, the function may
-choose to reschedule itself.
+timer functions. Timer functions always run with interrupts disabled.
+The timer functions should always complete within a few micro-seconds.
+At completion of the timer event, the function may choose to
+reschedule itself.
 
 In the event an error is detected the code can invoke shutdown() (a
 macro which calls sched_shutdown() located in **src/sched.c**).
@@ -188,8 +188,8 @@ provides further information on the mechanics of moves.
   with head movement even though the code is kept separate.
 
 * After the iterative solver calculates the step times they are added
-  to an array: `itersolve_gen_steps_range() -> queue_append()` (in
-  klippy/chelper/stepcompress.c). The array (struct
+  to an array: `itersolve_gen_steps_range() -> stepcompress_append()`
+  (in klippy/chelper/stepcompress.c). The array (struct
   stepcompress.queue) stores the corresponding micro-controller clock
   counter times for every step. Here the "micro-controller clock
   counter" value directly corresponds to the micro-controller's
@@ -220,11 +220,11 @@ provides further information on the mechanics of moves.
   runs the following, 'count' times: `do_step(); next_wake_time =
   last_wake_time + interval; interval += add;`
 
-The above may seem like a lot of complexity to execute a
-movement. However, the only really interesting parts are in the
-ToolHead and kinematic classes. It's this part of the code which
-specifies the movements and their timings. The remaining parts of the
-processing is mostly just communication and plumbing.
+The above may seem like a lot of complexity to execute a movement.
+However, the only really interesting parts are in the ToolHead and
+kinematic classes. It's this part of the code which specifies the
+movements and their timings. The remaining parts of the processing is
+mostly just communication and plumbing.
 
 Adding a host module
 ====================
@@ -338,9 +338,9 @@ Useful steps:
    operations.
 5. Other methods. Implement the `check_move()`, `get_status()`,
    `get_steppers()`, `home()`, and `set_position()` methods. These
-   functions are typically used to provide kinematic specific
-   checks. However, at the start of development one can use
-   boiler-plate code here.
+   functions are typically used to provide kinematic specific checks.
+   However, at the start of development one can use boiler-plate code
+   here.
 6. Implement test cases. Create a g-code file with a series of moves
    that can test important cases for the given kinematics. Follow the
    [debugging documentation](Debugging.md) to convert this g-code file