--- a/NOTES	Tue May 28 22:51:45 2019 -0400
+++ b/NOTES	Tue May 28 23:06:08 2019 -0400
@@ -5,7 +5,7 @@
 
 Current terminal widget:
 
-  * Run Octave in a separate thread.  On unixy systems, interact
+  * Run Octave in a separate thread.  On Unixy systems, interact
     through pty.  On Windows systems, use hidden console and mirror
     contents in a Qt widget.
 
@@ -53,7 +53,7 @@
       rl_prep_term_function (do nothing)
       rl_deprep_term_function (do nothing)
 
-   Call rl_callback_handler_install to setup readlines callback mode.
+   Call rl_callback_handler_install to setup readline's callback mode.
    This function sets the initial prompt and provides a pointer to a
    function that readline should call when a complete line of input is
    available.
@@ -77,11 +77,18 @@
     possible for the GUI to do useful things while the interpreter is
     busy.
 
+  * If the interpreter is not running in a separate thread but but the
+    graphics engine is, then what happens to graphics callbacks when the
+    parser has partially evaluated an expression?  Or is this not an
+    issue because separate parsers can be used even if there is only one
+    evaluator?  Could it ultimately be possible to have the evaluator
+    running in multiple threads?
+
   * If the interpreter does run in a separate thread, we still must
     wait for it to calculate and return a result so we can synchronize
     input and output.  Otherwise, we may print the next prompt before
     the output from the previous expression is evaluated and printed.
-    You'll see this behavior if you build the exampe program with
+    You'll see this behavior if you build the example program with
     CALC_USE_INTERPRETER_THREAD defined.
 
   * The example parser currently also performs evaluations and
@@ -92,12 +99,12 @@
 
   * Do we need text position markers to keep track of the prompt position
     (beginning of current line) when inserting or clearing text?  This
-    doesn't seem necessary in the current exmaple, but it doesn't have
+    doesn't seem necessary in the current example, but it doesn't have
     functions that can clear the screen or otherwise redraw prior output
     that would cause the position of the cursor in the window to change.
 
   * The example program doesn't attempt handle multi-line prompts or
-    prompts with invisible characters (color specificiations, for
+    prompts with invisible characters (color specifications, for
     example).  Fixing that will make the redisplay function
     significantly more complex.  See, for example, how complicated the
     default rl_redisplay function is in the readline library.  Unless
@@ -124,7 +131,7 @@
 
 readline callback functions:
 
-// -- Variable: rl_getc_func_t * rl_getc_function
+// -- Variable: Re_getc_func_t * rl_getc_function
 //     If non-zero, Readline will call indirectly through this pointer to
 //     get a character from the input stream.  By default, it is set to
 //     `rl_getc', the default Readline character input function (*note