This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: I wish...


Ideally, I think there should be a separate front-end processor for Guile.
I.e. a program that handles input editing, parenthesis bouncing,
perhaps ncurses-style window management, and that communicates
with a Guile "server".

Advantages:
* The Guile main program is leaner, because it does not have to
deal with termcap/terminfo, user editing, history, etc.

* There can be multiple front-ends (and multiple repls) connecting
to the same Guile server.

* There are event handling problems with a program that needs input
both from the controlling terminal and also GUI events.  (This is
certainly a problem for Kawa.)  Putting the terminal handling in
a separate program, and having Guile itself use (say) tcp to
communicate with the front-end processor, may help [though I
don't know enough to say for sure].

Of course, Emacs is such a front-end server.  However, it is not ideal.
It is big, and starts up slow.  It takes up a lot of screen real estate
(the right column - which makes cur-and-paste from emacs in xterm a pain,
status bar, mini-buffer line).  It executes slowly, because of the elisp.
So the ideal would be a fast, lean, front-end processor, written in C,
in a way that migh a useful front-end for multiple applications.
That is certainly my goal for Kawa;  perhaps a generic front-end
processor *framework* (kind of a stand-alone comint toolkit) might
be useful for a number of programs.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner