On 01/31/2009 11:00 PM, Glenn Morris wrote: Glenn, Don't forget that there was a peck of code that Dave Love took from python-mode.el in his python.el. Although he acknowledged it in the comments he used inline, if some of it was from Andreas, maybe rms is correct and python.el will have to be sidelined. Bev _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Sun, 01 Feb 2009 07:33:15 -0500, Barry Warsaw wrote: If Andreas' changes were to remain unmerged, would the merger of python-mode.el and python.el still be regarded as technically and/or legally impossible? Jeff _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

I'm glad to hear it's now GPLv3. From Emacs's point of view, we'd like to see the two converge, but this seems only possible if python-mode.el can be included in Emacs which requires its code to be assigned to the FSF. If the copyright assignment is reasonably possible, then I see no reason why the two code bases can't converge (clearly half the code would be thrown out, and there may be some tricky political work to do to get keybindings aligned, etc...). Last time this was brought up, the general sentiment was that, if merging is too difficult, it might be preferable to switch wholesale to python-mode.el (and then maybe try to retrofit some of python.el's featureset). Why is that? Too many contributors? Can't be tracked down? Won't sign papers? Stefan _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Maintenance is pretty significant problem, actually. The other problem is that all the Python coders I know install python-mode.el rather than use python.el. I don't know if it's representative, but if that's the case, then our users would be better served with python-mode.el included in Emacs. Yes, that sounds very good. But someone has to make this change to gud.el. Feel free to submit your patches here. Stefan _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

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 <fx(a)gnu.org&gt; wrote: 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 _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta