Re: push parser

[John W. Eaton]

On 28-Jan-2012, Rik wrote:

| On 01/28/2012 07:28 PM, address@hidden wrote:
| > Message: 4
| > Date: Sat, 28 Jan 2012 22:28:30 -0500
| > From: "John W. Eaton" <address@hidden>
| > To: octave maintainers mailing list <address@hidden>
| > Subject: using a push parser to connect Octave to a GUI
| >
| > Without a terminal widget, and using Octave this way, we
| > would not be able to use GNU readline.  OTOH, it might not be that
| > difficult to emulate enough readline keybindings to satisfy most GUI
| > users of Octave.
| OH NO!  Really?  I love Readline editing and while some basic editing is
| probably reproducible for the average user I can't imagine my setup would
| be supported.  I use Vi so I don't have the default Emacs key bindings and,
| worse, I use a Dvorak keyboard layout so my ~/.inputrc is pretty tricked out.

OK, I agree that it would be best to use the real thing rather than
implement just a subset.  So I thought about it some more and modified
the example GUI calculator so that it can use the real GNU readline
with a push parser generated by Bison.  It works by using GNU
readline's "callback" interface so that the GUI collects characters
and passes them to readline one at a time.  To handle I/O in the text
widget requires overriding some of readline's default functions.  To
do that, you just need to write a few functions and assign some
function pointers:

  rl_getc_function
    Get an input character from a file or some other source.

  rl_redisplay_function
    Display the current line as it is edited.
    
  rl_prep_term_function
    Prepare the terminal for readline.  For ttys, readline sets the
    terminal in raw mode so that characters are read as soon as they
    are typed.  For the GUI there is nothing to do.

  rl_deprep_term_function
    Return the terminal to its original state.  For the GUI there is
    nothing to do.

  rl_completion_display_matches_hook
    Display possible completions.  For my example code, I have this
    function displaying the completions in the terminal window,
    similar to the way readline does this by default for tty
    interaction.  But GUIs could also display completions in a
    separate window or temporarily split the command window to display
    completions, etc.  If you try the example code, TAB should be able
    to complete filenames at the prompt.

The current version of the code is attached below.  It is still not
complete as I have not tried to handle all special keys.  But many
readline features work.  Since it is GNU readline that is handling the
input, it should pay attention to the contents of your .inputrc file.

All the example code is still just 20k so I'm attaching it below.

| It seems like an interesting approach, but also a lot of work -- recode
| pull to push parser, make it re-entrant, code Readline equivalent.  All of
| this would then weaken the CLI, which I prefer, in order to facilitate a
| GUI for an operating system that I don't use.

Bison can generate both pull and push parsers for the same grammar, so
we don't have to change everything.  I think we could leave the tty
interface mostly as it is now.

Making the parser reentrant is not necessary.  Without that, we just
have to ensure that we don't call the parser for two separate input
sequences at the same time (for example, parse a .m file while we are
in the middle of parsing some command line input).  It should not be
too hard to prevent that from happening, as we only pass tokens to the
parser when a complete line is available.  I think the only time it is an
issue is when you are typing a statement or function definition that
at the command line that spans multiple lines of input.

| It could still be worthwhile for Octave as a project, rather than me
| personally, if a GUI is the thing standing between our current user base
| and widescale adoption.

That's what I keep hearing.  Plus, I keep hearing that having a GUI is
necessary for Windows users.  If it is possible to solve the problem
with ptys and a terminal widget, then great.  I was only hoping to
point out that there is another way to solve the problem that does not
require ptys.  This alternate way of organizing the event loop also
allows the GUI to be in complete control of events, which is something
that I think most GUI programmers expect.

jwe

gui-with-push-parser.tar.gz
Description: Binary data