Could Emacs be rewritten in Python?

[Christian Tanzer]

Carl Banks <imbosol-1050339953 at aerojockey.com> wrote:

> Christian Tanzer wrote:
> > All these functions (except the one you're writing) might have been
> > implemented years before the text properties and
> > `inhibit-point-motion-hooks` were introduced.
>
> See, that's really the problem.  It's obvious why history made Emacs
> what it is, but it doesn't change the fact that, as it stands now,
> Emacs is a terrible software design.

This kind of hubris is normally associated with Perl programmers, I
thought. Calling Emacs a terrible software design is similar to saying
that tea clippers had a terrible design because they didn't use an
engine...

Emacs is certainly a very successful application. Complex as it is, it
is very easy to program even for somebody like me who hates lots of
silly parentheses.

> Now, Emacs has a variable inhibit-point-motion-hooks.  If Emacs were
> currently designed well, this variable would not be needed, because
> functions would be able to operation without touching the point.

Not true. This has nothing to do with touching point but how cursor
movements behave. For example, searching doesn't work properly in some
cases unless you let `inhibit-point-motion-hooks` to a true value.

> Now, Emacs has a current bufferm, and a current point in a buffer,
> which all text operations take place it.  Right now, you have to use
> macros such as save-excursion and with-current-buffer, because right
> now, text manipulation functions implicitly use the current buffer and
> current point.  If Emacs were currently designed well, functions would
> accept a buffer to work on as an argument, and there would be no need
> to change the buffer temporarily.
>
> And so on.
>
> (As for things like buffer-local variables, I don't think it's a big
> deal to make them attributes of a buffer class.  Frame local
> variables, frame objects.  I think it's quite short-sighted to try to
> force buffer-local variables to be regular variables, and not what
> they obviously should be, attributes of the buffer, just because Emacs
> does it that way.)

Only partly true. Sure, a object-oriented design would make for a
better architecture and a better API. A pythonic solution certainly
would have buffer/frame/... objects with their respective attributes.
But there isn't that much difference between an attribute of a buffer
object (in the Python sense) and a buffer-locale variable (in the
Emacs sense).

You might be able to save some macros, but you would probably still
have lots of context which needs temporary changes for some functions
to work.

-- 
Christian Tanzer                                         tanzer at swing.co.at
Glasauergasse 32                                       Tel: +43 1 876 62 36
A-1130 Vienna, Austria                                 Fax: +43 1 877 66 92