Could Emacs be rewritten in Python?

[Beni Cherniavsky]

Patrick K. O'Brien wrote on 2003-04-07:

> Ian Bicking <ianb at colorstudy.com> writes:
>
> > On Mon, 2003-04-07 at 00:23, Carl Banks wrote:
> > > Third, there are a *ton* of functions in Emacs that operate on a
> > > certain point in a certain buffer (delete-char, kill-region, etc.).
> > > These kinds of functions typically get bound to keystrokes and other
> > > sorts of commands, which a user expects to work in the current buffer.
> > > If all these functions had to be passed the current buffer as an
> > > argument, it would just complicate things.
> >
> > Maybe instead they should be methods of the buffer, and a keystroke
> > automatically calls a method on the current buffer.
>
> That should be easy enough.
>
> > Managing so many methods from diverse sources might be difficult.  I
> > want generic methods, I keep thinking of places where they'd be mighty
> > useful... like Mixins but better.
>
> This I don't understand.  Could you elaborate?
>
I'm not Carl but I had similar thoughts, so I'll try :-).  Tons of
things in emacs are dependant on the "current something" and they are
usually inherited from more basic places in some ways.

So it would be nice to manage those things with classes / subclasses
and classes/instances.  Subclassing and multiple inheritance can be
used to merge them in appropriate ways.  Attribute access is used to
access everything.  With python's dynamism (think metaclasses), there
is enough flexibility to extend this scheme.

Each buffer will be an object.  It will have a lot of methods, like
`forward_sentence`, that come from different places, including the
current mode(s) of this buffer.

Cooperative super calls will be needed for things like keymap lookup
ot accomodate the need to look in more than one keymap.
Alternatively, you acn create a single default method to do keymap
lookup and it will dispatch to all appropriate methods / dicts of each
class involved that can then be written without bothering with
cooperation.

Hooks are just methods that can be implemented by subclasses.  Again,
you need multiple dispatch.  I really think that python's standard
behavior of attribute lookup won't fit all cases.  Emacs is full of
these things.  Every second library has some multiple dispatch
mechanism implemented.

Frequently the best approach is to define the cooperation policy in
the top class and write multiple plugins managed by this policy in the
subclasses (a different name is needed to avoid the shadowin, unless
you want to do metaclasses which will not play nice with dynamic class
changes I list below.  Some library of common policies might be
useful.

Now the issue is that the class - nay, the whole mro - of a buffer has
to be adjustable dynamically, e.g. when you switch modes.
Fortunately, Python allows class and basess changes.  This bringing of
many classes together is probably what Carl Banks talked about.  E.g.
minor modes are mixins - ones that you turn on and off on the fly!

If you want to closely mimick emacs, you can have *all* classes merged
into one emacs object.  Then you have one namespace and all knids of
buffer-local, etc things can be implemented.  Internally there aree
separate buffer, window, etc. objects but they all are exposed and
should be used through the same object.  So you access a property or
method (`self.paragraph_start`, `self.mark_function`) without knowing
whether it's hadled by the main global class, the current buffer's
class of anything else...

This sounds like a fun abuse of Python classes but I'm not sure it's
the right direction.  I think I'd rather see many objects.

-- 
Beni Cherniavsky <cben at tx.technion.ac.il>
When I grow up I want to write an Emacs.