Could Emacs be rewritten in Python?

[Martin v. Löwis]

pobrien at orbtech.com (Patrick K. O'Brien) writes:

> If you were crazy enough to think that you could create a program
> along the lines of Emacs, but written in Python, how would you go
> about it?  How would you design the domain model for files, buffers,
> windows, and frames?  How would you allow the same level of
> customizability?  How would you map functions (or methods or whatever)
> to keys?  Any thoughts?

This problem is underspecified, atleast for the actual implementation
strategy that follows: Do you need to support both terminal and GUI
mode? Multiple GUI libraries? Do you need API compatibility with Emacs?

> Here is the background.  I'm working on a file editor (called
> PyAlaMode) using wxPython and Scintilla.  It's an extension of the
> PyCrust code base.  I've got a basic version working, and it supports
> editing multiple files and all the usual, basic features.  But I want
> it to be as customizable and extensible as Emacs.  In fact, I want to
> model it after Emacs, so that elisp code could be rewritten in Python
> and work with PyAlaMode.  To do that, I've got to support the same
> primitives as Emacs; expose files, buffers, regions, and windows the
> same way Emacs does; handle the Emacs keybindings and ability to remap
> keys, the same way Emacs does, etc.

I think you don't have much design choices then, if you want to expose
the very *same* functionality. In fact, you have to chose whether you
want to make it compatible with Emacs or with XEmacs, and you have to
specify a specific release you target, as each release has its own API
modifications.

I recommend that you don't; there are certain aspects in Emacs that
are there for historical reasons only and that should be dropped. My
favourite here is the Emacs Mule representation, which represents
characters in multi-byte form, using ISO 2022 escape codes to switch
between character sets. I recommend that you use Unicode
instead. This, of course, means that an entire suite of elisp cannot
be readily ported to your editor, but must be rewritten.

I would suggest a bottom-up strategy rather than a top-down strategy:
Take your favourite elisp package (say, gnus, or python-mode), and try
to make it run. 

To do so, write an automated translator that translates all required
elisp files to Python code. Don't make that translator
perfect. Instead, make it just translate the files you are looking at,
and extend it as you find it fails to translate existing elisp code.
Special-case builtin functions in the translator as appropriate
(e.g. 'require).

Make the translator translate all elisp code. You will then find that
the package doesn't work, because there are primitive functions which
are defined in C, not in elisp. Try to write these functions in
Python, using the Scintilla and Python API.

That approach will require constant refactorization, but it will tell
you early on what you can expect and what is impossible to achieve.

Regards,
Martin