[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emebedding guile line command interpretor
From: |
Neil Jerram |
Subject: |
Re: emebedding guile line command interpretor |
Date: |
06 Feb 2001 22:25:25 +0000 |
>>>>> "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
Re: emebedding guile line command interpretor, Brett Viren, 2001/02/07