[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: Stefan Monnier
Subject: Re: Current state of python.el in the Emacs trunk
Date: Mon, 21 Feb 2011 17:25:58 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

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

"I gave up" is basically what I meant by "unwilling to maintain".
If you prefer that I say "we were not willing to have him as maintainer
under the terms he wanted" that's perfectly fine by me: I do not care
about whose fault it is.  I only care about improving our python.el and
making sure it stays well maintained.

> If I was mainatinaing it, I'd just do what I've been doing separately,
> which doesn't seem acceptable.

I do not understand the above sentence.

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

Presumably because, for lack of a maintainer, we integrate suboptimal
patches which solved incompatibilities between Python2 and Python3 by
splitting the file into two versions.

> and why changes were made which clearly broke things.

I don't know to which changes you're referring here.

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

But that does not help us much since (IIUC) you say that those changes
aren't covered by your assignment so we can't integrate them.

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

Bringing them closer to each other does not necessarily mean "take the
bad parts of python-mode.el".

BTW, regarding the global effect of pdbtrack, I agree that it's a bit
problematic, but at the same time this provides a form of integration
that some users really appreciate and which seems difficult to get
within something like GUD.
It'd be good to let users choose which one they want.


reply via email to

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