The status of merging the new python.el to the trunk
From:
Fabian Ezequiel Gallina
Subject:
The status of merging the new python.el to the trunk
Date:
Mon, 12 Sep 2011 01:08:24 -0300
Hi everybody,
This email is to give a heads up on the merge of the new python.el I'm maintaining and why it didn't happened yet (or no patch appeared on this mailing list)
Is not really a matter of loss of interest, the real reason is that the mode is supposed to be merged in a progressive way against the existing trunk's python.el, and it's not that I didn't tried to create the patches to it, but I feel kind of dumb when doing it. The main reason is that any part of the new mode depends on several things from it and that creates a cascade of dependencies that when I'm in the middle of the patch I have changed trunk's python.el almost completely making me feel the patch is not really useful at all.
Things that are easy to send in a separate patch:
* Font locking (it's almost the same code) * Utility functions (python-util-*)
And after that everything gets messy to me. Let's say I try to merge the navigation stuff, I have to merge the python-info* stuff too and then some of the old python.el indentation stuff depends on the navigation, so I'd have to fix that with the new navigation code or to put in place my indentation stuff. Of course I'd prefer the second since that code is really well tested and *boom* the patch gets bigger.
While new python.el started based on the old one, the internals and the code differs from it a lot, it really started as a drop-in replacement rather than a big patch with fixes for the original so that's why I think creating useful patches to merge the two is hard (at least for me, of course I might be stupid).
Long story short, I have almost given up in creating separate patches, and since I know maintainers will not include this mode in just one commit I'm thinking perhaps it is a good idea to nominate python.el for ELPA. If users starts using it and we see it is the favourite of both alternatives we can re-evaluate the possibility of moving it to the trunk (this time in just one commit).