Re: GUI terminal widget

[CROZIER Richard]

On 03/06/2019 17:34, Rik wrote:
> On 05/29/2019 09:00 AM, address@hidden wrote:
>> Subject:
>> Thoughts about a different approach to the GUI terminal widget
>> From:
>> "John W. Eaton" <address@hidden>
>> Date:
>> 05/28/2019 08:06 PM
>>
>> To:
>> Octave Maintainers List <address@hidden>
>> CC:
>> address@hidden
>>
>> List-Post:
>> <mailto:address@hidden>
>> Content-Transfer-Encoding:
>> 7bit
>> Precedence:
>> list
>> MIME-Version:
>> 1.0
>> Message-ID:
>> <address@hidden>
>> Content-Type:
>> text/plain; charset=utf-8; format=flowed
>> Message:
>> 1
>>
>>
>> Way back in January 2012, I posted the following message about
>> changing the terminal widget in the GUI to handle input differently.
>>
>>
>> http://lists.gnu.org/archive/html/octave-maintainers/2012-01/msg00416.html
>>
>>
>> I included a simple example written with gtkmm to illustrate the idea
>> of having the terminal widget in the GUI be in control of input and
>> output and feed lines of text to the interpreter.  To properly handle
>> input that spans multiple lines, a push parser is used instead of the
>> current pull parser.  It worked as an example, but was not much help
>> for Octave since we are using Qt.  So now I've reworked it using Qt
>> and you can find my sources here:
>>
>> http://hg.octave.org/jwe-qt-gui-with-push-parser
>>
>> See the NOTES file for build instructions.  That file also contains
>> the following list of open questions that will need to be resolved if
>> we are going to attempt a switch.
>>
>>   * With this arrangement, would the interpreter have to run in a
>> separate thread?  As the example shows, it's not absolutely 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 is not running in a separate thread but but the
>> graphics engine is, then what happens to graphics callbacks when the
>> parser is in the middle of parsing 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 example 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 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 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 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 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.
>>
>> Now that I have an almost working (if quite simplistic) example in Qt,
>> I will attempt to modify Octave to use this approach. From that, I
>> expect many more questions to come up.
>>
>> jwe
>
> jwe,
>
> I didn't see any comments at https://wiki.octave.org/GUI_terminal_widget
> so I thought I would bring the conversation back to the mailing list.
>
>  From a strategic level, this is a big change.  What do we get from
> doing this (pros) and what do we lose (cons)?  Are there sufficient
> benefits to undertake this task?
>
> Although the terminal often causes problems, it also allows for a lot of
> code re-use.  We use Readline for history and input processing.  We get
> 'less' and other utilities for free.  In replacing this, do we
> essentially need to re-invent the wheel? That's a *lot* of coding effort
> for something that isn't even particularly Octave related.  Since your
> time is finite, if you are working on this then there will be other
> Octave bugs that aren't addressed.  Is the balance worthwhile?  You
> understand core Octave better than anyone so it may be that your time is
> better spent resolving 50 bugs there, rather than writing more generic
> terminal emulation code that other programmers could do.
>
> Just some ideas on what to answer before going forward.
>
> --Rik
>


The terminal code in Octave is a mess, I have gone in to try and fix
bugs, but it is so complex (for example there is, or at least was,
completely different terminal code for Windows and Linux), that fixing
simple bugs had a huge overhead in understanding the terminal code.

Given that no-one has done anything to improve this for a long time
perhaps JWE's help is needed to get the terminal to a state where others
can help pick things up, especially if he has done some of the work already.

I also get the impression he's enjoying getting this working. Enjoyment
is important for a project maintainer!

Incidentally, do you really need a pager in the gui? You have scrollbars
on the windows. All you really need is a keyboard shortcut to scroll up
don't you? Like SHIFT+PageUp

I also wonder if there is a lot which can be lifted/translated from the
Jupyter Qt console:

https://github.com/jupyter/qtconsole

It has a history and a pager.

Regards,

Richard







The University of Edinburgh is a charitable body, registered in Scotland, with 
registration number SC005336.