[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Current state of python.el in the Emacs trunk

From: Dave Love
Subject: Re: Current state of python.el in the Emacs trunk
Date: Mon, 21 Feb 2011 00:48:39 +0000
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)

Stefan Monnier <address@hidden> writes:

> The only problem is that the very
> reason for desiring such a switch is because nobody (including and
> especially the most obvious candidate, Dave) has been willing to
> maintain our python.el.

I wasn't unwilling to maintain it, and I attempted in the past to get
the Emacs version fixed and prevent problems being introduced, but that
was rather unrewarding, and I gave up.  It's not appropriate anyway, as
rms seems to think I act in bad faith these days.  If I was mainatinaing
it, I'd just do what I've been doing separately, which doesn't seem
acceptable.  I haven't checked exactly what's currently in Emacs, but
I'm baffled why, for instance, it got three .py files instead of a more
maintainable one, and why changes were made which clearly broke things.

> Now Fabian proposes a third Python mode.  That sounds like adding innnsult
> to injury, but I must say it is very tempting:
> - its copyright is clean, like our python.el.
> - he seems interested in maintaining it.

I don't know what that's about, but I maintain a version with no unfixed
bugs I'm aware of, and had various features (and not misfeatures) the
others don't.  Until I started working on it at the university, it was
covered by an assignment (given potential problems with my previous
employment were disregarded) and could just have been used.  It may well
need to be fixed for the incompatible Emacs changes that get made, but
I'd fix it if told, and if it didn't break it for released versions.

> Of course, I'd rather work at bringing the various python modes closer
> to each other, rather than have them fork even further, so I'm not sure
> what's the best course here.

Why?  python.el was intentionally different from python-mode.el for
various reasons, like being a well-behaved Emacs (as opposed to XEmacs?)
mode.  I don't understand why you'd want something whose distinction as
far as I can tell is violating conventions with fewer features and extra
bugs.  Actually, after all the propaganda about it, python.el code now
seems to be migrating into python-mode.el (after stripping the copyright
headers, contrary to the licence, of course).

I do find this all pretty sad.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]