From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Current state of python.el in the Emacs trunk Date: Mon, 21 Feb 2011 17:25:58 -0500 Message-ID: References: <4D40F55C.2040400@gmail.com> <874o85t61z.fsf@liv.ac.uk> <87y65hukcj.fsf@stupidchicken.com> <87r5b2kyag.fsf@liv.ac.uk> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1298327200 29251 80.91.229.12 (21 Feb 2011 22:26:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 21 Feb 2011 22:26:40 +0000 (UTC) Cc: Christoph , Chong Yidong , "emacs-devel@gnu.org" To: Dave Love Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 21 23:26:35 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 1PreCy-0005xM-RB for ged-emacs-devel@m.gmane.org; Mon, 21 Feb 2011 23:26:33 +0100 Original-Received: from localhost ([127.0.0.1]:49259 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PreCu-0000bw-SE for ged-emacs-devel@m.gmane.org; Mon, 21 Feb 2011 17:26:16 -0500 Original-Received: from [140.186.70.92] (port=41071 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PreCo-0000bj-4d for emacs-devel@gnu.org; Mon, 21 Feb 2011 17:26:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PreCf-0001sQ-9m for emacs-devel@gnu.org; Mon, 21 Feb 2011 17:26:02 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:25776 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PreCf-0001sH-5B; Mon, 21 Feb 2011 17:26:01 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEZ1Yk1MCqhK/2dsb2JhbACmPnS7IIVeBIUNj1E X-IronPort-AV: E=Sophos;i="4.62,202,1297054800"; d="scan'208";a="92985483" Original-Received: from 76-10-168-74.dsl.teksavvy.com (HELO ceviche.home) ([76.10.168.74]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 21 Feb 2011 17:25:58 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id AD179660D3; Mon, 21 Feb 2011 17:25:58 -0500 (EST) In-Reply-To: <87r5b2kyag.fsf@liv.ac.uk> (Dave Love's message of "Mon, 21 Feb 2011 00:48:39 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:136348 Archived-At: > I wasn't unwilling to maintain it, and I attempted in the past to get > the Emacs version fixed and prevent problems being introduced, but that > was rather unrewarding, and I gave up. "I gave up" is basically what I meant by "unwilling to maintain". If you prefer that I say "we were not willing to have him as maintainer under the terms he wanted" that's perfectly fine by me: I do not care about whose fault it is. I only care about improving our python.el and making sure it stays well maintained. > If I was mainatinaing it, I'd just do what I've been doing separately, > which doesn't seem acceptable. I do not understand the above sentence. > I haven't checked exactly what's > currently in Emacs, but I'm baffled why, for instance, it got three > .py files instead of a more maintainable one, Presumably because, for lack of a maintainer, we integrate suboptimal patches which solved incompatibilities between Python2 and Python3 by splitting the file into two versions. > and why changes were made which clearly broke things. I don't know to which changes you're referring here. > I don't know what that's about, but I maintain a version with no unfixed > bugs I'm aware of, and had various features (and not misfeatures) the > others don't. But that does not help us much since (IIUC) you say that those changes aren't covered by your assignment so we can't integrate them. >> Of course, I'd rather work at bringing the various python modes closer >> to each other, rather than have them fork even further, so I'm not sure >> what's the best course here. > Why? python.el was intentionally different from python-mode.el for > various reasons, like being a well-behaved Emacs (as opposed to XEmacs?) > mode. I don't understand why you'd want something whose distinction as > far as I can tell is violating conventions with fewer features and extra > bugs. Bringing them closer to each other does not necessarily mean "take the bad parts of python-mode.el". BTW, regarding the global effect of pdbtrack, I agree that it's a bit problematic, but at the same time this provides a form of integration that some users really appreciate and which seems difficult to get within something like GUD. It'd be good to let users choose which one they want. Stefan