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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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


        Stefan