From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christoph Newsgroups: gmane.emacs.devel Subject: Re: A new major-mode for Python Date: Wed, 16 Feb 2011 20:58:49 -0700 Message-ID: <4D5C9CF9.6020002@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1297915149 10018 80.91.229.12 (17 Feb 2011 03:59:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 17 Feb 2011 03:59:09 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org, galli.87@gmail.com To: monnier@iro.umontreal.ca Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 17 04:59:04 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ppv1E-0007oa-At for ged-emacs-devel@m.gmane.org; Thu, 17 Feb 2011 04:59:04 +0100 Original-Received: from localhost ([127.0.0.1]:55747 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ppv1D-0007sY-Ra for ged-emacs-devel@m.gmane.org; Wed, 16 Feb 2011 22:59:03 -0500 Original-Received: from [140.186.70.92] (port=47419 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ppv19-0007sD-Km for emacs-devel@gnu.org; Wed, 16 Feb 2011 22:59:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ppv18-00088a-En for emacs-devel@gnu.org; Wed, 16 Feb 2011 22:58:59 -0500 Original-Received: from mail-yi0-f41.google.com ([209.85.218.41]:42397) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ppv18-000889-BM for emacs-devel@gnu.org; Wed, 16 Feb 2011 22:58:58 -0500 Original-Received: by yia25 with SMTP id 25so1023707yia.0 for ; Wed, 16 Feb 2011 19:58:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=mKsc3K1zllshr/WeuavJAj4Yila7u/Bm28KhOjhjHL8=; b=gIN+XWdG6Mu6c9hlh5An493zzMTxDjALbcXOlE2ybozAJj5996M3dhhU2CnD333q7s s3XVZbLJabnU/+wCZJqvgjGJkV+g7C3YydrOzKeXMCERyWC6IgHoP9Q1a9IJQzGNPHTd 0Bn8S+IzCT8WW1DzrWnAha86PoyZYHIBXlh8I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=asVrZP50v0AbmbvayEyO+frxw2c3WxrDKoXY/MOvVQbKwtYoicm7sJsIK36IQXjGf3 UFHs2ctudwHiSbyNNLdufPqCQn0iTqxhTanvWcfBFL/VymuXM1YBneiIxhC9ytlcpsA0 EBOsZgdSGPGKOnrkkpIBXUEGKHt+zn/LqxNc8= Original-Received: by 10.146.167.7 with SMTP id p7mr2094229yae.10.1297915136612; Wed, 16 Feb 2011 19:58:56 -0800 (PST) Original-Received: from [192.168.1.2] (71-208-192-11.hlrn.qwest.net [71.208.192.11]) by mx.google.com with ESMTPS id g63sm339669yhd.15.2011.02.16.19.58.53 (version=SSLv3 cipher=OTHER); Wed, 16 Feb 2011 19:58:55 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.218.41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:136128 Archived-At: Stefan Monnier 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". [...] > 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. 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. 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? Christoph