The status of merging the new python.el to the trunk

The status of merging the new python.el to the trunk

[Fabian Ezequiel Gallina]

[-- Attachment #1: Type: text/plain, Size: 2053 bytes --]

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


What do you think?


Regards,
Fabián E. Gallina

[-- Attachment #2: Type: text/html, Size: 2151 bytes --]

Re: The status of merging the new python.el to the trunk

[Rasmus]

Hi,

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

I have used Fabián's python.el for a some time.  It is very good, also
better that Python Foundation's python-mode and certainly a lot better
than what is included in Emacs now.  Personally, I wouldn't mind it
entirely replacing Love-Python in Emacs with or without patching up the
old code.

–Rasmus

-- 
Sent from my Emacs

Re: The status of merging the new python.el to the trunk

[Stefan Monnier]

> Things that are easy to send in a separate patch:

> * Font locking (it's almost the same code)
> * Utility functions (python-util-*)

Then please send this along.

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

Is https://github.com/fgallina/python.el your working code?
I'll try and take a look.  I've bumped into such problems in the past, so
I combine a few useful assets: experience in those problem, intimate
knowledge of Emacs maintainer's expectations (e.g. his willingness to
accept intermediate states that aren't perfect), plus a lot of influence
over that same Emacs maintainer.


        Stefan