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] |
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