Could Emacs be rewritten in Python?

[Carl Banks]

Christian Tanzer wrote:
> 
> 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.

That it's a successful application is irrelevant to whether it's a
good design.  (Exhibit A: Any Microsoft program.)

That it's easy for you to program is something that need not disappear
with a good design.  However, 




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

The cursor *is* the point, chief.

Things like searching move the point around, because Emacs is a flawed
design and only works in the context of the point.  That's why you
need inhibit-point-motion-hooks: in a search, the point moves all over
the place unbeknownst to the user, and it would really confuse things
and cause problems if hooks the user installed whenever the point
(i.e., the cursor) moves get called during a search operation.

A good design wouldn't abuse the point like this.  The point would be
the place where user input happens, nothing more.  Functions that
wanted to do something in the buffer away from point wouldn't *have*
to move it.  And we wouldn't need a hack like
inhibit-point-motion-hooks.


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

I don't even understand the point you're trying to make.

In any case, the two are very different: buffer-local variables are
variables, and so they need a namespace, and an odd one.  Buffer
attributes have none of the complicated namespace issues, since
they're attributes.


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

I think you're very wrong.


-- 
CARL BANKS