From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: A new major-mode for Python Date: Wed, 16 Feb 2011 10:34:15 -0500 Message-ID: <87y65ghu2w.fsf@stupidchicken.com> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1297870473 5108 80.91.229.12 (16 Feb 2011 15:34:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 16 Feb 2011 15:34:33 +0000 (UTC) Cc: Stefan Monnier , Emacs-Devel devel To: Fabian Ezequiel Gallina Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 16 16:34:28 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 1PpjOe-0006Rc-H5 for ged-emacs-devel@m.gmane.org; Wed, 16 Feb 2011 16:34:28 +0100 Original-Received: from localhost ([127.0.0.1]:54288 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PpjOe-0001LG-2b for ged-emacs-devel@m.gmane.org; Wed, 16 Feb 2011 10:34:28 -0500 Original-Received: from [140.186.70.92] (port=40937 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PpjOZ-0001L8-I5 for emacs-devel@gnu.org; Wed, 16 Feb 2011 10:34:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PpjOY-0004U4-Kk for emacs-devel@gnu.org; Wed, 16 Feb 2011 10:34:23 -0500 Original-Received: from vm-emlprdomr-05.its.yale.edu ([130.132.50.146]:33646) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PpjOY-0004Tx-GV for emacs-devel@gnu.org; Wed, 16 Feb 2011 10:34:22 -0500 Original-Received: from furball (dhcp128036226132.central.yale.edu [128.36.226.132]) (authenticated bits=0) by vm-emlprdomr-05.its.yale.edu (8.14.4/8.14.4) with ESMTP id p1GFYG7t000744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Feb 2011 10:34:16 -0500 Original-Received: by furball (Postfix, from userid 1000) id 4D8AC1604E2; Wed, 16 Feb 2011 10:34:15 -0500 (EST) In-Reply-To: (Fabian Ezequiel Gallina's message of "Wed, 16 Feb 2011 03:46:47 -0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Scanned-By: MIMEDefang 2.71 on 130.132.50.146 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.132.50.146 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:136107 Archived-At: Fabian Ezequiel Gallina writes: > The possibility of being the maintainer is never a crappy offer, but > I'm really scared about the effort we would put into doing the kind of > merge you propose, I can't really see that approach as > productive. (The mode I wrote shares *very little* code with trunk's > python.el) > > It was at that time I started thinking in writing a python mode from > scratch in order to have a *clean* working version of the things I > expected from it. The result is this thing I uploaded to github :) It's good to have a clean working version as the base from which to work, and I don't object in principle to removing functionality that's truly not needed. But it's preferable to make changes in the trunk code systematically. Even though the mode you wrote does not closely match what's in the trunk, it should still be possible to break it up into separate pieces. For example, the first step could involve replacing python-beginning-of-defun and python-end-of-defun and the functions they use (i.e. the the indentation engine). This would allow other hackers to study the diff, and figure out (i) in what ways the new code really is an improvement, (ii) whether any features are lost, and (iii) whether any commands and customizable options, on which users might depend, are lost or changed in a backward-incompatible way. And then repeat the procedure for the other parts: font lock, python shell support, pdbtrack support, and so forth. It is a bit more work than just dumping a brand new file into place. But I don't think it's an unreasonable amount of work, especially if other hackers are willing to help, and the advantages would be great.