# HG changeset patch
# User John W. Eaton <jwe@octave.org>
# Date 1558704155 14400
# Node ID bfa9aaa2d6080ef36366987ca7ae86b77b5e8ad2
# Parent  79783f3e201799d7527f6f8e20858897fad515ce
update NOTES

diff -r 79783f3e2017 -r bfa9aaa2d608 NOTES
--- a/NOTES	Fri May 24 09:22:29 2019 -0400
+++ b/NOTES	Fri May 24 09:22:35 2019 -0400
@@ -69,15 +69,27 @@
 Questions:
 
   * With this arrangement, would the interpreter have to run in a
-    separtae thread?
+    separate thread?  As the example shows, it's not absolutely
+    necessary, but it could offer some advantages, but only if it is
+    possible for the GUI to do useful things while the interpreter is
+    busy.
 
-  * Example parser currently computes results
-    immediately.  How do we deal with parsing multiple expressions and
-    statements with this method?
+  * 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
+    wouldn't have this problem because we already build a parse tree
+    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?
 
+  * This 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.
 
 readline callback functions: