Hello,

  Ah yes, of course the purpose should not be to port an
existing editor to Squeak, but to create something better.

>> 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.
> 
> The Emacs distribution has 275,860 lines of C (including .h files) and
> 507,035 lines of Emacs Lisp.  I suspect that a lot of that C doesn't
> map trivially to Smalltalk. :)  So yes, it's probably *that* bad.

  We don't have to port the Emacs lisp interpreter code
(including the memory management and other things) of Emacs.
And a certain part of the other C code is only Lisp code
written in C syntax so actually we could map most of them to
Squeak:-) In this respect, it is not that bad.

  On the other hand, why I think it would be "lots of labor"
is that the presense of the "imcompatibility" of Elisp and
Squeak.  For example, Elisp is dynamic scoped language while
Squeak is not.  Look at this:

(setq c 3)
   => 3
   "c is globally bound to 3"

(defun func (a)
  c)
   => func
   "function func returns the value bound to c"

(func 1)
   => 3
   "returns 3, as expected"

(defun caller (a)
  (let ((c 2))
    (func a)))
   => caller
   "caller returns the value of func, but?"

(caller 1)
   => 2
   "not 3.  the returned value is a 'temp' of function foo"

  This is just an example, but there would be issues that
make simple mapping from Elisp function to Squeak method
impossible.  Rewriting those "elisp specific code" would not
be difficult, but I think it can be a lot of labor.

  -- Yoshiki