Lex Spoon wrote:
> 
> Doug Way <dway at riskmetrics.com> wrote:
> >
> > Option #3 (truly "plugging in an emacs editor") is probably nearly as huge a task as #4, if you really want to get the various lisp-emacs libraries working.  (This is no fault of Squeak's... it would be no easier to, say, try to get a X-based CAD package to run inside a lisp-emacs environment.)  But, on the other hand, someone (Nishihara Satoshi) has already written a simple Lisp interpreter in Squeak, which you could play around with and try to build off of.  See http://minnow.cc.gatech.edu/squeak/1410 .
> >
> 
> Can you say why you think this would be such a huge task?

Mostly gut feeling :), and the sheer size of the standard Emacs distribution, which includes a fair amount of C code (as Randal said).  I'm not enough of a lisp guru to know exactly where the biggest problems would be... I mostly wanted to dispel the naive idea that Squeak is some sort of lower-level graphics library that you could fairly easily plug an emacs editor into. (not that anyone was seriously arguing that point)

Also, Smalltalk and Lisp are both similarly high level languages, so it doesn't really seem that practically useful to try to integrate the two (as opposed to using Smalltalk with C, which is very useful), although I agree it would be interesting.  (Probably a better idea to reimplement important aspects of emacs in Smalltalk, such as the text-editing aspects that Bijan mentioned...)

I was also sort of hoping to spur discussion on this, by getting someone to refute my claim with a simple solution that none of us had thought of, if one existed. :)  Anyway, I did say "nearly as huge", not impossible.  Your breakdown below sounds like a reasonable starting point.  Probably "very large" would be a reasonable assessment. :)

- Doug Way
  dway at riskmetrics.com


> E-lisp has
> the advantage of being a very simple language.  It seems the "only" big
> tasks required are:
> 
>         1. Map Emacs's data structures such as "buffers" and "frames" into
> something relevant for Squeak.
> 
>         2. Implement all the primitives (which requires a good solution to #1).
> 
> I don't have a feel for how large these tasks are, but it doesn't seem
> like it should be *that* bad.  The really hard part seems to be the
> mapping in #1.  Eg, perhaps there could be one Squeak window per buffer,
> and the "mini buffer" could accept commands via pop-up windows, and the
> messages window is Transcript.  One has to come up with parallels like
> this for all of Emacs's fundamental data structures.
> 
> -Lex
> 
> PS -- one can also think about what one misses from emacs.  For example,
> it seems harder in Squeak to script key strokes (except in Genie!).
> Also, there is no support for editting foreign textual formats -- every
> text pane is optimized for editting Smalltalk code.