# HG changeset patch # User John W. Eaton # Date 1559098305 14400 # Node ID 7e93b74bd6c293478ebb286a7d6a0b25b66c1040 # Parent 2ddf3fe6fa33f768ac8dae04b5cf0d5cd707a258 update NOTES diff -r 2ddf3fe6fa33 -r 7e93b74bd6c2 NOTES --- 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: