emacs and squeak, again...

Lex Spoon lex at cc.gatech.edu
Sun Feb 25 17:53:08 UTC 2001


Doug Way <dway at riskmetrics.com> wrote:
> 
> Phil Mitchell wrote:
> > 
> > Thanks, Yoshiki. Yes, you're right, a lot of what I want to do could be done
> > in elisp using emacs as the platform, but then I have no way to tie in nice
> > gui components, which seems a shame in the 21st century. I've thought about
> > using gnuserv, I don't know if that will be flexible enough to be really
> > usable. "Reimplement the whole thing" -- I'm not sure what you mean. Emacs?
> 
> I think he meant reimplementing all of the functionality of Emacs by rewriting it in Squeak/Smalltalk.  Of course, this would be an enormous task.  (Yoshiki's Option #4, that is.)
> 
> But more realistically, you could just implement (in Squeak/Smalltalk) some of the most important text editor features that you want, one at a time, which is much more do-able.  For example, just implementing the basic cursor navigation controls would be fairly easy... (I think someone has probably already done this at some point).  (I guess this is Option #0.)  And many common lisp text processing commands probably already have equivalents in Smalltalk.
> 
> 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?  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.





More information about the Squeak-dev mailing list