--- a/NOTES	Tue May 28 18:27:18 2019 -0400
+++ b/NOTES	Tue May 28 22:51:45 2019 -0400
@@ -5,43 +5,46 @@
 
 Current terminal widget:
 
-  * Run Octave in a separate thread.  On unixy, interact through pty.
-    On Windows systems, use hidden console and mirror contents in Qt
-    widget.
+  * 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.
 
-    Octave interpreter sees input directly, same as for normal
-    terminal application.  Good, because no change in the way Octave
-    accepts and parses input.  Bad because GUI is not in control of
-    input and must arrange to communicate across threads.
+    The Octave interpreter sees input directly, same as for normal
+    terminal application.  This approach is good, because no change in
+    the way Octave accepts and parses input is necessary.  But it is
+    bad because GUI is not in control of input and must arrange to
+    communicate across threads.
 
-    Terminal window can (in theory) be used to run other applications
-    started from the system command (for example).  This feature works
-    well enough for us to use less running as a separate process to
-    handle paging output, but it doesn't work for all applications.
-    For example, I am not able to run editors like Emacs or vi in the
-    GUI terminal window.
+    The terminal window can (in theory) be used to run other
+    applications started from the system command (for example).  This
+    feature works well enough for us to use "less" running as a
+    separate process to handle paging output, but it doesn't work for
+    all applications.  For example, I am not able to run editors like
+    Emacs or vi in the GUI terminal window, even on Unixy systems.
 
-    To make less work as the pager on Unixy systems, the Octave must
-    fork, call setsid in the child to detach from the controlling
-    terminal, and then exec the GUI.
+    To make "less" work as the pager on Unixy systems, the Octave
+    process must fork, call setsid in the child to detach from the
+    controlling terminal, and then exec the GUI.
 
-    GUI must deal with threads when communicating with the
+    The GUI must deal with threads when communicating with the
     interpreter.
 
 Proposal:
 
-  * GUI terminal widget is in control of input.
+  * Create a new GUI terminal widget that is in control of input.
 
-    Use callback interface for readline to handle command line
-    editing.
+    Use the callback interface for readline to handle command line
+    editing.  As the internal line changes, it is the job of the new
+    GUI terminal widget to redisplay the updated text of the line that
+    readline is used to edit.
 
-    Use push parser to parse lines as they become available.  Push
-    parser will return status of parse, either complete or needing
-    more input.
+    Use a push parser to parse lines as they become available.  The
+    push parser will return the status of the parse as either complete
+    or needing more input.
 
-    Uses the following readline callbacks to manage input and update
-    the display.  We may need more in the future to handle other
-    features.
+    The GUI terminal widget uses the following readline callbacks to
+    manage input and update the display.  We may need more in the
+    future to handle other features.
 
       rl_getc_function
       rl_redisplay_function
@@ -50,10 +53,10 @@
       rl_prep_term_function (do nothing)
       rl_deprep_term_function (do nothing)
 
-   Call rl_callback_handler_install to setup readlines
-   callback mode.  This sets the initial prompt and provides a pointer
-   to a function that readline should call when a complete line of
-   input is available.
+   Call rl_callback_handler_install to setup readlines 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.
 
    Call rl_callback_read_char when a character is available for
    readline to handle.  We currently store the character to read in a
@@ -70,10 +73,17 @@
 
   * With this arrangement, would the interpreter have to run in a
     separate thread?  As the example shows, it's not absolutely
-    necessary, but it could offer some advantages, but only if it is
+    necessary.  It could offer some advantages, but only if it is
     possible for the GUI to do useful things while the interpreter is
     busy.
 
+  * 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
+    CALC_USE_INTERPRETER_THREAD defined.
+
   * The example parser currently also performs evaluations and
     computes results immediately so it doesn't properly handle
     expression lists that are split across multiple lines.  Octave
@@ -81,15 +91,36 @@
     then execute it once it is complete.
 
   * Do we need text position markers to keep track of the prompt position
-    (beginning of current line) when inserting or clearing text?
+    (beginning of current line) when inserting or clearing text?  This
+    doesn't seem necessary in the current exmaple, 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.
 
-  * This example program doesn't attempt handle multi-line prompts or
+  * The example program doesn't attempt handle multi-line prompts or
     prompts with invisible characters (color specificiations, for
     example).  Fixing that will make the redisplay function
     significantly more complex.  See, for example, how complicated the
-    default rl_redisplay function is.  Unless we actually write a
-    terminal emulator (like the current terminal widgets) then it is
-    not possible to use readline's rl_redisplay function directly.
+    default rl_redisplay function is in the readline library.  Unless
+    we actually write a terminal emulator (like the current terminal
+    widgets) then it is not possible to use readline's rl_redisplay
+    function directly.
+
+  * We'll need to implement a pager ourselves, since "less" won't work
+    in this simplified terminal widget.
+
+  * The system function may need to be modified so that external
+    programs that expect to be running in a terminal will continue to
+    work properly.  On Unixy systems, this job can be done with ptys.
+    I guess Windows systems can use a hidden console?  But if these
+    things are required, are we more or less back to were we were
+    before since we used a pty and hidden console to implement the
+    terminal widgets?  I believe the Emacs start-process function must
+    do similar things, so we might be able to reuse that code.
+
+  * If readline runs in the terminal widget, who owns the command-line
+    history?  Either way, if the GUI is in control of keyboard input,
+    it will need access to the history list and Octave will also need
+    access for the history functions.
 
 readline callback functions: