Could Emacs be rewritten in Python?

[Patrick K. O'Brien]

martin at v.loewis.de (Martin v. Löwis) writes:

> pobrien at orbtech.com (Patrick K. O'Brien) writes:
> > 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.

Since I'm only looking for 95% compatibility, I should think a recent
release will be fine.  I'm using GNU Emacs 21.2.1.

> 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 agree that warts like this should be removed.  And I don't expect to
be able to convert elisp in a completely automated fashion.  But the
API and basic behavior (is that redundant?) need to be as similar as
possible.  Which means how files, buffers, the minibuffer, windows,
etc. are created and exposed to elisp code needs to be understood and
modeled in Python.  I have an understand from a user point of view,
but I need a better understanding from a desing and implementation
point of view in order to code it in Python.

> 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. 

I agree.  In fact, python-mode is my first target.

> 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).

Are there translators out there?  I looked and couldn't find any.  I
wonder if Pymacs could be useful for this.

> 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.

That's pretty much the approach I planned to take, after I got some of
the more basic pieces in place.  For example, file handling.  If you
try to save a file and another process has modified it, Emacs warns
you.  Where is that kind of code kept in Emacs?  Is it in elisp, or
part of the core Emacs written in C?  Is there a document anywhere
that gives an overview of the design of Emacs that would answer these
kinds of questions?

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------