<div class="gmail_quote">On Fri, Jan 21, 2011 at 5:34 AM, Jerry James <span dir="ltr"><<a href="mailto:loganjerry@gmail.com">loganjerry@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div id=":59">The thing that keeps preventing me from seriously pursuing this is<br>
actually character and string encodings.  ECL is UTF-32 inside, isn't<br>
it?  I don't even know where to start with porting a MULE-inside<br>
(X)Emacs to a Unicode-inside CL.  In the XEmacs code base, we have<br>
probabilistic character encoding detectors, and so forth, all of which<br>
would have to be made to work in a Unicode world.  It's so daunting<br>
that every time I think about just experimenting a little with putting<br>
a CL engine inside, I think about this, and change my mind. :-(</div></blockquote></div><br>What I was suggesting was not replacing (X)Emacs internal structures with ECL's. That would be foolish. Instead I consider it to be more reasonable an approach that first links in ECL, exposes (X)Emacs buffers and objects to ECL, adds an API for Common Lisp programs to manipulate buffers, load files, and do all that Elisp can do; then add a elisp->CL interpreter and at some point do the switch.<div>

<br></div><div>Juanjo<br clear="all"><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>


</div>