Could Emacs be rewritten in Python?

[Beni Cherniavsky]

François Pinard wrote on 2003-04-11:

> [Beni Cherniavsky]
>
> > To clarify the issue completely, the emacs lisp manual contains a
> > must-read section:
>
> > http://www.gnu.org/manual/elisp-manual-21-2.8/html_node/elisp_147.html#SEC147
>
> > [...] It also describes some implementation details - not that I believe
> > we want dynamic scope... [...]
>
> Oh, I would not say that the above text is clarifying the issue completely.
> It rather gives a flying glimpse over the problem, within the context of a
> discussion about a project considering a rewrite of Emacs in Python.
>
You're right; I drop the "completely" ;-).  I only meant the classic
lexical/dynamic scopings, not all the variants emacs has...

> For example, the shallow binding implementation is not really acceptable for
> buffer local variables, even if most non buffer local variables use it.  Not
> to speak about the complexity associated with various defaulting or
> initialising mechanism for variables in buffers.
>
Hmm, buffer-local things are an interesting idea in emacs.  It
approximately amounts to running a separate emacs in every buffer.

> Bindings are also different, despite simultaneous, for functions and for
> non-functions.

You mean it's a "LISP2" while Python is "LISP1"?  I don't see any
architectural importance to it, it's just a matter of local convenince
w.r.t. naming things.

> Over these two, properties allow one to simulate many concurrent
> flavours of bindings to symbols.

You mean Python's descriptors/properties, or LISP's properties
attached to symbols?

> Evaluation contexts may also be fully switched through usage of
> alternate obstacks.
>
I don't really follow you here.  Care to explain?

> Now, key bindings are another kind of binding which does not work exactly
> like variables, yet the project quoted above might be wise to consider as
> well.  For example, key bindings may be associated with limited text areas
> within buffers, ...



> ... and while the cursor moves between windows, or over text
> within windows, key bindings may change quite often.  Emacs uses heaps (some
> call them priority stacks) for tracking these changes.
>
Really?  I always thought it simply searches all active keymaps.
Searching one is quick (it's a trie) and how many are there at once?
You only do keymap lookup when the user presses something so this
doesn't seem to be speed-critical.  I must miss something if emacs
bothers to optimize it - but what?

> So, all in all, in real practice, we have a flurry of different
> types and qualities of bindings with Emacs, and a variety of
> implementation techniques for them.

I think implementation techniques are secondary; first we should
choose what behavior we want.  Would be nice to get a list of all
kings of bindings/lookups.  XEmacs did some interesting generalization
of some of them - "specifiers":

http://xemacs.org/Documentation/21.5/html/lispref_45.html#SEC624

Looks to me like they are onto something but didn't carry it far
enough :-).

One type that comes to mind that is not currently good enough in emacs
is combining and switching groups of settings under user control.
Any big enough mode seems to implement something in this direction -
e.g. cc-mode's "styles", bunches of variables saved in lists given
names switchable by the user.  That kind of thing should be availiable
in any place around, perhaps as part of the custom system - but there
should be good support for having different "themes" active in
different buffers/modes/something at the same time.

What this all reminds me is the cascading in CSS.  People keep
reinventing the idea of lookup in several places in order of priority
all the time: X resources, CSS, emacs keymaps, multiple config files
(every self-respecting unix program supports at least 2: site-wide and
per-user), emacs buffer-local variables defaulting to the global
binding...

> It would not be wise to underestimate the problem, or to quickly
> dismiss this complexity as being gratuitous.
>
I completely agree.  I didn't mean to understimate it.

-- 
Beni Cherniavsky <cben at tx.technion.ac.il>