From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ken manheimer Newsgroups: gmane.emacs.devel,gmane.emacs.python-mode,gmane.emacs.xemacs.beta Subject: Re: replacing python.el Date: Thu, 19 Feb 2009 15:21:00 -0500 Message-ID: <2cd46e7f0902191221p74b2061aqde130167dcff4cab@mail.gmail.com> References: <4980316B.7080503@online.de> <87wsc96fu1.fsf@liv.ac.uk> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1235074947 8878 80.91.229.12 (19 Feb 2009 20:22:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Feb 2009 20:22:27 +0000 (UTC) Cc: "skip@pobox.com" , "rms@gnu.org" , "python-mode@python.org" , "XEmacs-Beta@xemacs.org" , "barry@python.org" , "fbe2@comcast.net" , "emacs-devel@gnu.org" To: Dave Love Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 19 21:23:40 2009 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.50) id 1LaFQX-0000Yh-04 for ged-emacs-devel@m.gmane.org; Thu, 19 Feb 2009 21:23:21 +0100 Original-Received: from localhost ([127.0.0.1]:52325 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LaFPC-0008Ax-KW for ged-emacs-devel@m.gmane.org; Thu, 19 Feb 2009 15:21:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LaFOO-0007ce-Lr for emacs-devel@gnu.org; Thu, 19 Feb 2009 15:21:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LaFOM-0007bc-T1 for emacs-devel@gnu.org; Thu, 19 Feb 2009 15:21:08 -0500 Original-Received: from [199.232.76.173] (port=53946 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LaFOM-0007bW-NH for emacs-devel@gnu.org; Thu, 19 Feb 2009 15:21:06 -0500 Original-Received: from mail-bw0-f160.google.com ([209.85.218.160]:54723) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LaFOI-0004V6-0G; Thu, 19 Feb 2009 15:21:02 -0500 Original-Received: by bwz4 with SMTP id 4so1656684bwz.18 for ; Thu, 19 Feb 2009 12:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GrpJhM/MJknXlT1JTy1GJjMWwhJQiUnKcfxbnh7+gyI=; b=gKInHDeUZ2T3YHKVHHeZqu0GTttxf0mdrASjrYKsAEQdwHRMM4viz6dKbhoVBfi8nS XeaqelCVte+AgH7jm4lrT6LLSWQ0JzLR9BpZ5Eic3zx0B4qNYL38nuORTjUsPk11p2gE ECZOlg0RvM4ChMtlEH4B/o7Ia63FXU2fiCsVw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KANsTFjDchbs+28gT/kkmurRgFQ41fgywMrzq7B+vaxNulJJQqd3HUCQaY9YkO9KKC 0nriK+Gg2eMl/Yvx/5mKH0279TnG6ipFUHfDl/zpeuOzWhxvENsXjLbBMgPdgPPDfkPh +i89uGHUyOUfP2sR1sSK5o89FJSB3znduL8CI= Original-Received: by 10.181.193.15 with SMTP id v15mr1183545bkp.168.1235074860643; Thu, 19 Feb 2009 12:21:00 -0800 (PST) In-Reply-To: <87wsc96fu1.fsf@liv.ac.uk> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:109231 gmane.emacs.python-mode:271 gmane.emacs.xemacs.beta:29426 Archived-At: sorry to be late to this python.el / python-mode.el convergence discussion. i'm concerned that what dave is describing would not preserve a crucial feature of pdbtrack, a feature that may be a reason some python developers choose python-mode.el over python.el. (it is for me.) On Sun, Feb 1, 2009 at 3:51 PM, Dave Love wrote: >[...] > Indeed, and I don't understand what other problem there is with it, > other than maintenance. Why does it need to be replaced with > python-mode.el, even if that was properly assigned? > > The only other worthwhile feature I know of sort-of from python-mode.el > is related to something called pdbtrack (?). My commentary explains > that part of the functionality already exists, and something more > general than the rest should be a general feature in GUD. (The > Python-specifics are already there.) It's not difficult to restructure > GUD -- or wasn't when I hacked it originally -- and it's not clean to > make an add-on, which is why it's not in python.el. I know there isn't > interest in abstractions like that, but I didn't want to preempt a > possible change of opinion. when i last looked at it, gud was a terrible fit for pdbtrack. if things haven't changed drastically, i'm concerned that what you're suggesting would sacrifice pdbtrack's dynamicism. this is all the more worrisome since i spent some time porting pdbtrack to python.el. it's currently there in emacs 23.0.90, but i see it's not in the emacs that comes w/recent ubuntu, emacs 22.2. here's the scoop, as best i can describe it. gud is oriented to being in control of debugging, in particular launching the program being debugged, or injecting a connection to the executive to start the debugging at an arbitrary point, or post-mortem. pdbtrack, on the other hand, simply works wherevever python's debugger, pdb, does. the pdbtrack code is responsible for detecting pdb activity within an (any) emacs shell and presenting, in a companion buffer, the source file and line that pdb is reporting as the current instruction. pdbtrack provides functionality for python's debugger, pdb, much like edebug does for emacs lisp, except that pdb can be triggered as a statement within the subject program's code, and not just taking over execution of the program (as gdb and edebug do), or run onerror/post-mortem. (pdb also provides those modes.) this turns out to be invaluable in general, and especially for long-running programs like servers, where you want debugging to trigger in very specific situations. with pdb, you just situate the debug-triggering code exactly in the situation (i wish i could do this with edebug), or as error handling around the situation. gud may have facilities that could be used to enhance pdbtrack, but i don't think it is designed to operate the way i describe above. plus, gud is massive, and i suspect it would take more emacs lisp code to craft gud python accommodations than all of pdbtrack (last i checked around 150 lines, including copious comments). i hope this is clear. as i said, pdbtrack porting to python.el has already been done, it just isn't in the currently released version. and, of course, there are other benefits to be had from a python-mode.el/python.el convergence, but i want to make sure this one, at least, is preserved. (i also think the pdbtrack approach would be appreciated for other dynamic languages, including emacs lisp.) -- ken http://myriadicity.net