emacs-devel
[Top][All Lists]
Advanced

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

Re: A new major-mode for Python


From: Fabian Ezequiel Gallina
Subject: Re: A new major-mode for Python
Date: Thu, 17 Feb 2011 15:22:42 -0300

2011/2/17 Christoph <address@hidden>:
> Stefan Monnier <address@hidden> writes:
>
>> I'm not so much concerned about backward compatibility, really.  I just
>> would rather have a smoother transition.
>
> I think the move can be done step by step and shouldn't take too long
> overall.
>
>> I'm not too concerned about features.  I just want the transition to be
>> done in meaningful chunks.  E.g. one commit can rip out the old
>> indentation and install your new one.  Another one could be "drop
>> bycicle because noone wants to repair the repairman".

Sounds reasonable to me. Let's do it.

>
> [...]
>
>> I think we can work something out.  And if Christoph is OK with helping
>> along, this could go very smoothly.
>
> I am OK with that.
>
> Here is what I would propose for the next steps:
>
> If Fabian is OK with the general approach described by you and Chong and
> OK with signing the FSF papers, he should go ahead and do that. In the
> meantime, we could polish Fabians implementation as hosted on github and
> start thinking about the integration in steps.

I do agree, and I sent the form request already, they should get back
to me soon.

>
> By polish, I mean a) resolve issues the current implementation has (I have
> been using it for a couple of days and found a couple, especially on
> Windows) and b) implement the features that are in the Emacs' python.el but
> not in Fabians implementation and that we don't want to loose.
>
> I am available in whatever capacity Fabian is comfortable, i.e. as a
> tester/bug reporter or I can provide patches for improvements.
>

Any help is appreciated, I assume you have signed the papers already
so any contribution will be OK to inclusion.

> As for the integration with the current python.el, I think that some
> cleanup is needed first. For example the pdbtrack implementation that
> was done a couple of years ago pulled in all this unecessary code that
> was never cleaned up. I would clean up this part right away. Then maybe
> remove bicycle repair main support and other stuff that we decide is not
> really required. I think, this will make integrating Fabians changes
> easier.
>
> Fabian, what do you think?
>

That sounds nice. If you could start those cleanups in the current
python.el part the merge should get even simpler.


Regards,
-- 
Fabián E. Gallina
http://www.from-the-cloud.com



reply via email to

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