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: Translators to guile



> How will one write the display code? Theoretically a curses wrapper, once
> it works reliably, could do that on a text console, but would be horribly
> slow and in addition one would need to some totally different approach for
> e.g. gtk or harmony display , which is not supported by yet the GNU emacs, 
> and the existing athena, motif and plain x11 stuff. So that would be a
> lame approach. Something general stubs, written in C, with dynamically 
> loadable frontends for termcap, gtk, harmony, athena, tk, lesstiff, ... 
> would sound fine and possibly more efficient. Are there any plans to do so?

In GNU Emacs, all the display code is written in C, not lisp.
Lisp can manipulate buffers and such, and the C code takes care of
updating the display automatically.

We'd just replace the lisp interpreter with Guile, not the remaining
code.  The redisplay code would remain in C, as would the buffer
implementation, subprocess handling, and so on.

> And the big 3 scripters, i.e. perl, python and tcl, should also come asap,
> but perl and tcl have a syntax that are a pain in the tail to handle, let
> alone the semantics. The other string processing languages (m4, awk etc.)
> aren't much better. Somehow those string processing langs have yet an 
> important role in many GNU tools which are to be replaced with guile once
> possible: automake, autoconf, dejagnu on top of them.

Meshing the data worlds of two different languages is a... fascinating
problem.  :)