Re: emebedding guile line command interpretor

[Neil Jerram]

>>>>> "Hilaire" == Hilaire Fernandes <address@hidden> writes:

    Neil> Right.  Personally, I'd go for option 3.  To see roughly
    Neil> what you need to do, take a look at the files
    Neil> gtk-1.2/gtk.scm and gtk/event-repl.scm

    Hilaire> Well this is the option I will do in last as it invovle
    Hilaire> rewritting an interactive shell

I don't follow your logic here.  The key distinction is if you are
happy for your Guile repl to look like it's running in its own window,
like an xterm, or if you need the repl to be more integrated,
e.g. inside a GtkText widget.  Sorry for not being clear about this
before.

The "xterm" look can be achieved by any of the suggested options
without needing to rewrite large parts of Readline.  The differences
between the options are different programming models, one of which may
suit your application better than the others.  Chris Baker has
recently used a variant of option 3 - based on the files mentioned -
in his application and reported that it worked well; see the
guile-user archive for the relevant exchange.

The "integrated" look inevitably requires some hacking to connect
Readline's back end with Gtk, or else to rewrite a lot of Readline for
Gtk.  Again, this is true for all 3 suggested options.

(This would be _so_ useful, though.  Perhaps someone somewhere has
already done it?)

Going back to the options, I think I may have misled you on option 1:
I don't think it works to call Guile from more than one OS thread.  To
get round this, the Guile thread could send instructions down the pipe
in a form that doesn't need Guile at the other end.  Or, as Georges
suggested, you could separate further into two processes and
communicate via a socket.

Best regards,
        Neil