Re: [Python-mode] Towards a PDEE
Barry Warsaw wrote: On Mar 22, 2010, at 12:32 PM, Andreas Roehler wrote: as the colors themes matter indicates, idea of an integrated python developing environment meets some wider interest. Which raises the question where to proceed. I'm probably not the best person to participate in this. While I definitely can understand the appeal and applaud the effort to provide Python developers with a really fantastic Emacs-based development environment, it's probably not something I would personally use. But hey, I'm old so ignore me and go for it! :) Maybe exists something which will still raise you up :) Integrating more stuff might result into an collection like emacs-w3m. BTW if entered that path, suggest a split of current python-mode.el too, think smaller files grouped thematically as for pdb for example are easier to debug. Not to get folks bewildered, suggest to keep stuff as is in python-mode.el at the known place. But making up a second location, mirroring classic python-mode, augmented by other useful stuff as ipython, maybe color-theme etc. I think you'll have problems keeping two different locations for the same functionality in sync. I'm not in favor of splitting python-mode.el up much personally because I think it's really easy for people to grab and install as one file. Perhaps think about building optional tools around python-mode and keeping python-mode.el as the basic support for .py file editing? I see no reason why this larger effort couldn't be housed inside the python-mode project on Launchpad though, as long as we continue to make it easy (and obvious) how to download and install python-mode.el for those wanting something simpler. -Barry Could realise the augmented mode via branches. Whats needed so far is a separate tar-archive delivering it. A problem not solved that way is the info. `color-theme' for example is quite another item than python. If a branch contains up to hundred el-files then, how to document and/or explain the matter? A step forward maybe would be a closer integration of already existing stuff: presently, if python-mode is on, it knows nothing about doctest-mode... Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] simple comment/string-tweak branch
Barry Warsaw wrote: On Mar 16, 2010, at 04:22 PM, Tom Roche wrote: Perhaps this will be useful. As I know little about your procedures, had never used bzr at all until yesterday, and had never done a bzr commit until 10 min ago, please let me know if anything needs done better/ correctly. I think you did it just about perfectly. I've reviewed and accepted the merge proposal. Maybe Andreas would like to merge and push it? -Barry done ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Don't bind C-c C-h
Barry Warsaw wrote: On Mar 19, 2010, at 05:12 PM, Reinout van Rees wrote: On 03/19/2010 04:21 PM, Barry Warsaw wrote: Any objections to C-c C-e? None at all. That e-for-explain you mentioned sounds fine. Cool. Bug updated. -B Fix is here: lp:~a-roehler/python-mode/dont-bind-C-c-C-h-541833 Merge? Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] 23.1.92; python-expand-template docu
Hi, python.el provides templates inserting compound statements like `if', `for' etc. - a nice feature. AFAIS it's for use in two ways - 1) as an abbrev expanded 2) by calling `python-expand-template', afterwards the user is prompted. See only the first usage mentioned in the docu. The latter may be more suitable for beginners, as it's done expressingly only - no automatic abbreviation expansion. Suggest to extend the docstring of `python-use-skeletons' with something like In any case you may use skeletons, calling `python-expand-template'. Also description of `define-derived-mode python-mode' which closes now: An abbrev table is set up with skeleton expansions for compound statement templates. should mention `python-use-skeletons'. Thanks all Andreas -- https://code.launchpad.net/~a-roehler/python-mode https://code.launchpad.net/s-x-emacs-werkstatt/ GNU Emacs 23.1.92.1 (i686-pc-linux-gnu, GTK+ Version 2.12.0) of 2010-02-19 ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] form inserting print
Georg Brandl wrote: Am 12.03.2010 10:51, schrieb Andreas Roehler: Hi python-mode folks, form below should speed up writing print-statements in Python a little bit. (defun druck (optional arg) Inserts a print statement out of current `(car kill-ring)' by default, inserts ARG instead if delivered. (interactive *) (lexical-let* ((name (or arg (car kill-ring))) (form (cond ((eq major-mode 'python-mode) (concat print \ name : %s \ % name) (insert form))) Opinions? Wouldn't that be the job of one of the numerous snippet packages that are floating around? Probably. I'm using yasnippet myself, and it works very well. For me too. (I know that python.el has some definitions for skeleton mode, but python-mode.el doesn't, and I'm not sure it should.) Thanks for the hint. `python-expand-template' works fine for me. For conditionals starting with `if' or `try' it should pay having it. Andreas Georg ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] small units
Barry Warsaw wrote:
On Mar 05, 2010, at 07:00 PM, Andreas Roehler wrote:
question is: how to edit small units in python-code?
Let's consider piece below from Dive Into Python:
result = roman71.fromRoman(numeral)
Beside of operators three python-words are here:
result / roman71 / fromRoman(numeral)
which should possible be picked with one command/key.
Resp. copied, deleted, maybe transposed etc.
Aren't there already key bindings for these. E.g.
M-f == py-forward-into-nomenclature
that's ok
Python-units, `python-expressions' finally, behaves different:
1) it selects and highlights the item
2) stops at the beginning, resp. the last char of item
3) takes the item into the kill-ring when interactively called
4) provides a series of related commands, reports, hiding etc.
M-C-f == forward-sexp
Shows occasionally unpredictable behaviour, for example
def __init__(self, d={}):
__|__
self._keys = d.keys()
dict.__init__(self, d)
If cursor is under closing brace
forward-sexp: Scan error: Containing expression ends prematurely, 565, 566
`ar-forward-python-expression-atpt' in contrast would move to the closing `)'
with first step, than to the next `self' etc.
BTW seems I have to clean up my launchpad-repo
For the curious, in order to get everything needed, two checkouts seem
necessary:
bzr branch lp:~a-roehler/s-x-emacs-werkstatt/thingatpt-python-expressions.el
bzr branch lp:~a-roehler/s-x-emacs-werkstatt/beg-end.el
Andreas
Well you need two keystrokes to get all of 'fromRoman(numeral)' or of course
you could just use
C-e == move-end-of-line
At least, it's never seemed there was anything lacking to me.
-Barry
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] small units
Hi, question is: how to edit small units in python-code? Let's consider piece below from Dive Into Python: result = roman71.fromRoman(numeral) Beside of operators three python-words are here: result / roman71 / fromRoman(numeral) which should possible be picked with one command/key. Resp. copied, deleted, maybe transposed etc. Any ideas? Thanks Andreas -- https://code.launchpad.net/~a-roehler/python-mode https://code.launchpad.net/s-x-emacs-werkstatt/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] coding in emacs 23
Jeff Bauer wrote: After upgrading to emac23, I noticed one big difference in editing python code ... or, well editing anything. 0123456789012345678901234567890123456789 1 One-really-long-line-of-text-and-newline 2 -doesn't-appear-until-full-stop-HERE. 3 Second-line-of-code It used to be if my cursor was positioned on (0,1) and I pressed ^N, Hmm, probably a most basic key binding, ignore it nonetheless Could you describe this a little bit, tell the command name behind? BTW assume you are referring to python.el, not python-mode.el, right? Andreas -- https://code.launchpad.net/s-x-emacs-werkstatt/ the cursor would jump down to the second line of code (0,3). Now it goes to (0,2) which is still considered (0,50). I think I preferred the older behavior for coding -- especially when I'm ThinkingInPython. Now I grab a line of code only to look up and realize I've only grabbed the first portion of the python statement. This also messes up the way I used to do some on-the-fly macros. Anyone else affected by this disconnect? ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] testing fixes-328781-bod-lands-in-string
Hi Barry, attached a test-file, which does some move-checks on branch https://code.launchpad.net/~a-roehler/python-mode/fixes-328781-bod-lands-in-string/+merge/18030 Also it checks last merge introducing hide-show support. As tests went well, set branch for merge. BTW wrote tests with perspective of further extensions, every ...-test-forms addressing a patch: (defun ar-py-mode-tests-intern ... (ar-py-mode-mv-test-forms) (ar-py-mode-hs-test-forms) ) Comments welcome. So far Andreas -- https://code.launchpad.net/s-x-emacs-werkstatt/ ar-python-mode-tests.el.gz Description: GNU Zip compressed data ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] [Merge] lp:~freiksenet/python-mode/hide-show-support into lp:python-mode
Barry Warsaw wrote: On Jan 18, 2010, at 2:43 AM, Andreas Roehler wrote: Barry Warsaw wrote: Oops, that was the wrong branch. Andreas, please review this branch yourself and mark it approved if you want. Then merge this branch and push it. OK, merged locally. Got M python-mode.el All changes applied successfully. Seems I have to do a commit still. After this: push into the trunk? Correct. Uses --fixes when you do a commit (see 'bzr help commit') and attach the bug number. Don't see a bug number here - it's just an extension. Going to commit without...(?) Andreas Then when you push, Launchpad should update all the data. ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Problem with Multi-Line Comments
Kent Borg wrote: Andreas Roehler wrote: no need for that, emacs -q or emacs -Q is the right thing then emacs -q does not work, emacs -Q does work. (The toggling of highlighting while opening and closing a multi-line comment is like before, seems normal, seems the way it proceeds but inside a correct multi-line comment, a new ' is happily ignored.) reads like ok now. Patch attached - not polished yet, but works here some weeks now. Copied it to my /usr/share/emacs/site-lisp/python-mode Tried: # patch python-mode.el tqs-all-python-mode.patch It seemed to work. To check: # diff python-mode.el python-mode.el-351 ...seems to look like the patch file. New emacs doesn't work better, but do I need to open the new python-mode.el and meta-X byte-compile-file or something? Just make sure it's loaded. For example put (load PATH-TO-NEW-python-mode.el) into your .emacs Comment out old python-mode loads if any. BTW byte-compile is very seldom needed, only if speed matters. Usually you'll not remark a difference. The only common use for me while playing with single files - compiling displays possible errors. python-mode.elc has a new time stamp, does that mean I did it correctly? Thanks, -kb, the Kent who has never gotten into emacs internals and doesn't know the difference between a -q and -Q launch. After reading An Introduction to Programming in Emacs Lisp you'll enjoy Emacs much more probably: M-x info RET m emacs lisp TAB ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] [Bug 450552] Re: python-mode breaks for python 3
...
Hi Rustom,
seems I have a ipython-bug here.
with
print 3 * 4
in foo.py
I get the correct result only first time in a separate buffer without ipython.
Afterwards always strange output:
IPython 0.8.1 -- An enhanced Interactive Python.
object? - Details about 'object'. ?object also works, ?? prints more.
[0;32mIn [[1;32m1[0;32m]: [0m12
Last number 12 is the correct output.
Seems some encoding from shell-processes wrong...
;
However, don't think it's related to our patch - attached.
May you try it? Thanks!
Hi Barry,
so far a first draft how to do it. Comments welcome.
Andreas
--- /home/speck/arbeit/python/python-modes/python-mode/python-mode.el 2009-10-16 18:55:37.0 +0200
+++ /home/speck/arbeit/python/python-modes/bug-450552-exec/python-mode.el 2009-11-02 23:08:02.0 +0100
@@ -368,6 +368,90 @@
:type 'string
:group 'python)
+(defcustom py-python-major-version
+ *Different Python versions affect python execution and editing.
+Python-mode will adapt itself to a version specified.
+Otherwise python-mode will try some guess from the installed system.
+You may switch the addressed python-version with M-x py-switch-addressed-version.
+ :type 'string
+ :group 'python)
+(make-variable-buffer-local 'py-python-major-version)
+
+(defcustom py-guess-python-version t
+ *Specifies whether to guess the py-python-major-version when a buffer is
+visited. Defaults to t.
+ :type 'string
+ :group 'python)
+(make-variable-buffer-local 'py-guess-python-version)
+
+(defvar py-python-major-version-default-value 2
+ Use this value if py-python-major-version is empty and `py-guess-python-version' set to nil)
+
+(defvar py-exec-command nil
+ Command set by `py-versions-compatibility-function')
+
+(defun py-versions-compatibility-function ()
+ Set values according to python version.
+Addresses incompatibilities beween different versions of python itself.
+ (interactive)
+ (let ((version
+ (cond ((not (string= py-python-major-version))
+py-python-major-version)
+((when py-guess-python-version
+(py-guess-python-version)))
+ (t py-python-major-version-default-value
+(set-py-exec-command version)))
+
+(defun py-change-python-version (optional arg)
+ Make `set-py-exec-command' ignore values specified by `py-python-major-version', `py-guess-python-version' resp. `py-python-major-version-default-value'.
+Set it herewith resp. get prompted for it.
+ (interactive)
+ (let ((version (cond (arg arg)
+ (t (read-from-minibuffer Python version: )
+(when (not (string= version))
+(setq py-python-major-version version)
+(when (interactive-p) (message py-python-major-version: %s py-python-major-version))
+py-python-major-version)))
+
+(defun set-py-exec-command (version)
+ With Python 3.0 `execfile(fn)' has been replaced by `exec(open(fn).read())'.
+http://docs.python.org/dev/3.0/whatsnew/3.0.html
+For Python 3.0 this function replaces
+\(format \execfile(r'%s') # PYTHON-MODE\\n\ filename)
+by
+\(cmd (format \exec(compile(open('%s').read(), '%s', 'exec')) # PYTHON-MODE\\n\ filename filename))
+as suggested by Rustom, https://bugs.launchpad.net/bugs/450552
+
+ (setq py-exec-command
+;; (quote
+(cond ((not (string= py-exec-this-command))
+ (quote py-exec-this-command))
+ ((string-match ^[^0-9]+2 version)
+ '(format execfile(r'%s') # PYTHON-MODE\n filename))
+ (t '(format exec(compile(open('%s').read(), '%s', 'exec')) # PYTHON-MODE\n filename filename
+ (message py-exec-comand set to %s py-exec-command))
+
+(defcustom py-exec-this-command
+ *Usually `py-exec-command' is selected from environement by
+setting vars `py-python-major-version' resp. `py-guess-python-version'.
+If not satisfied with these results, py-exec-this-command will overwrite it.
+
+ :type 'string
+ :group 'python)
+
+(defun py-guess-python-version ()
+ (interactive)
+ (let ((oldbuf (current-buffer))
+(version
+ (progn (set-buffer (get-buffer-create Python-Version))
+(erase-buffer)
+(shell-command python --version Python-Version)
+(goto-char (point-min))
+(when (re-search-forward Python.+ nil t 1)
+ (match-string-no-properties 0)
+(when (interactive-p) (message %s version))
+version))
+
(defcustom py-shell-switch-buffers-on-execute t
*Controls switching to the Python buffer where commands are
executed. When non-nil the buffer switches to the Python buffer, if
@@ -1349,8 +1433,8 @@
(procbuf (process-buffer proc))
; (comint-scroll-to-bottom-on-output t)
(msg (format ## working on region in file %s...\n filename))
-;; add some comment, so that we can filter it out of history
-(cmd (format execfile(r'%s') # PYTHON-MODE\n filename)))
+
Re: [Python-mode] [Bug 450552] Re: python-mode breaks for python 3
Rustom Mody wrote:
On Tue, Oct 20, 2009 at 1:59 PM, Andreas Roehler
andreas.roeh...@online.de mailto:andreas.roeh...@online.de wrote:
Rustom wrote:
(cmd (format exec(compile(open('%s').read(), '%s', 'exec')) #
PYTHON-MODE\n filename filename)))
For me both of your variants are working, see output of checks below.
uname -a python --version cat 2+4.py cat exec-read.py python
exec-read.py
cat exec-compile-read.py python
exec-compile-read.py
==
Linux ... 2.6.22.19-0.2-default #1 SMP 2008-12-18 10:17:03 +0100 i686 athlon
i386 GNU/Linux
Python 2.5.1
#! /usr/bin/env python
# -*- coding: utf-8 -*-
print 2 + 4
##
#! /usr/bin/env python
# -*- coding: utf-8 -*-
exec(open('2+4.py').read())
##
6
#! /usr/bin/env python
# -*- coding: utf-8 -*-
exec(compile(open('2+4.py').read(), '2+4.py', 'exec'))
#
6
;
BTW can you tell whats the us of `compile' here for you?
Do you have some tests for python-mode.el?
What puzzles me still is a pure python question -
do we need this `read()' here, i.e. if a file opened is
delivered to exec, will it not being read anyway?
Thanks
See Guido's 2 to 3 doc
http://docs.python.org/dev/3.0/whatsnew/3.0.html#removed-syntax
says stream argument not taken
Ah, thanks
Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] [Bug 450552] Re: python-mode breaks for python 3
Rustom wrote:
On Thu, Oct 22, 2009 at 8:32 PM, Andreas Roehler
andreas.roeh...@online.dewrote:
...
Rustom wrote:
(cmd (format exec(compile(open('%s').read(), '%s', 'exec'))
#
PYTHON-MODE\n filename filename)))
For me both of your variants are working, see output of checks below.
You probably need to try on windows.
See
http://bugs.python.org/issue5524
Hmm, AFAIU the use of `compile' here on windows is to signal an error if
the file contains \r chars?
Right?
The way I understood it the exec want Unix-only lineendings and compile
avoids the whole issue by supplying exec with a code object and not a
compilable text.
But I may be wrong
Probably you are right - if the `\r'-error doesn't occur
with `compile'. Think we should make a comment, saying
compile here is introduced for this side-effect.
Do you have some tests for python-mode.el?
As in automated el/py etc? No
As in biological? ...
If you may deliver a simple test case, how to call interactively it from
inside emacs,
it might be helpful - at least for me... :)
Not sure what you are asking for.
Your emacs startup should contain something like
(autoload 'py-shell python-mode Python Inferior Mode. t)
(autoload 'python-mode python-mode Python Mode. t)
(add-to-list 'auto-mode-alist '(\\.py\\' . python-mode))
(add-to-list 'interpreter-mode-alist '(python . python-mode))
Also assuming that python-mode.el is in your path
After that opening a file with .py extension should start in python mode
From there C-c ! should start the python interpreter
After that (from the file buffer) C-c C-c should read the file into the
python interpreter buffer.
But as I said I am not sure what you are asking for :-)
Sorry. Simply tried to catch the execution of your form with edebug.
The ways I tried, it wasn't called.
Thanks anyway.
Andreas
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] [Bug 450552] [NEW] python-mode breaks for python 3
Rustom wrote: Public bug reported: python 3 has removed execfile This makes python-mode stop working In function py-execute-file changing the line (cmd (format execfile(r'%s') # PYTHON-MODE\n filename))) to (cmd (format exec(open(r'%s').read()) # PYTHON-MODE\n filename))) seems to solve the problem ** Affects: python-mode Importance: Undecided Status: New IMO it's not to cure by changing a line in general. More bugs will be around due to different flavours of python. Versions of python 2.4.+ are in use still AFAIK. 2.5.+ or 2.6.+ will remain widely used Will a single python-mode be able to cope with this differences? IMHO: yes, however it must to address some issues. Herewith some outlines what seems necessary: - specifying by a variable the version where edits are for (customizable) - some guessing, which python-version might be in used, if user didn't set it - displaying python-versions-variable in mode-line - auto-adapting code, editing and execution resp. to the mentioned version. - possible switch between versions-specifics, updating the modeline etc. Introducing a first item in this line might read: (defcustom py-adressed-python-version *With different Python versions, changes have been made, which affect python execution as editing likewise. If a version is specified here, python-mode will adapt its proceeding to it. Otherwise python-mode will try some guess from the installed system. You may switch the addressed python-version with M-x py-switch-addressed-version during your emacs-session. :type 'string :group 'python) Any hints, objections, ideas? Thanks! Andreas -- https://code.launchpad.net/s-x-emacs-werkstatt/ http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] simplifying beginning-of-defun (2)
Below again the code, as end-of-defun-raw had a bug last times ;; GNU's lisp.el ;; unhappily sets this var globally, ignoring its use for progmodes (when (featurep 'emacs) (setq end-of-defun-function nil)) (setq defun-searchform '(if defun-prompt-regexp (concat ^\\s(\\| \\( defun-prompt-regexp \\)\\s() ^\\s()) (defun beginning-of-defun (optional arg) Move backward to the beginning of a functions definition. (interactive P) (or arg (setq arg 1)) (if beginning-of-defun-function (funcall beginning-of-defun-function arg) (beginning-of-defun-raw arg))) (defun beginning-of-defun-raw (optional arg) Called if progmodes didn't set beginning-of-defun-function. (when (re-search-backward (eval defun-searchform) nil 'move (or arg 1)) (goto-char (match-beginning 0 (defun end-of-defun (optional arg) Move backward to the end of a function. (interactive P) (or arg (setq arg 1)) (if end-of-defun-function (funcall end-of-defun-function arg) (end-of-defun-raw arg))) (defun end-of-defun-raw (optional arg) Called if progmodes didn't set end-of-defun-function. (skip-chars-forward \t\r\n\f) (unless (looking-at (eval defun-searchform)) (beginning-of-defun 1)) (when (re-search-forward (eval defun-searchform) nil t arg) (goto-char (match-beginning 0)) (forward-sexp 1))) ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] hs-minor-mode, add-to-list
Hi Mikhail, intend to propose your patch for XEmacs. Having a look at it at again, see you removed - (unless (assoc 'python-mode hs-special-modes-alist) remains (setq hs-special-modes-alist (cons (list Think it was a useful check, as loading python-mode at several occasions will cons it again and again. The best form to avoid that is not `(unless (assoc' IMO, but the use of add-to-list instead of cons. If agreed, may you change that so far? Thanks Andreas -- https://code.launchpad.net/s-x-emacs-werkstatt/ http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] beginning-of-defun-function.patch
Barry Warsaw wrote: On Sep 13, 2009, at 6:29 AM, Andreas Roehler wrote: as mentioned, several modes like C++ or python-mode need a more sophisticated determination of beginning- or end-of-defun than a regexp may provide. A additional function-call will be possible with patch attached. It allows use of `M-x end-of-defun' in python-mode for example. Should no one object, I'll try to check it in into the mercurial repo. I think you meant the Bazaar repo? :) Not this time. :) It's a patch agains XEmacs lisp.el, providing a call of end-, resp. beginning-of-defun-function from beginning-of-defun/end-of-defun. Its a feature available in GNU Emacs, but not in XE. (Was buggy in GNU last time btw.) Can you do a proper branch and merge proposal for this change? Please create a bug too. It just helps us track things much better. Will keep that in mind. Andreas -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] beginning-of-defun-function.patch
Hi, as mentioned, several modes like C++ or python-mode need a more sophisticated determination of beginning- or end-of-defun than a regexp may provide. A additional function-call will be possible with patch attached. It allows use of `M-x end-of-defun' in python-mode for example. Should no one object, I'll try to check it in into the mercurial repo. Cheers Andreas Röhler -- https://code.launchpad.net/s-x-emacs-werkstatt/ http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/ --- MY-PATH/xemacs-21.5/lisp/lisp.el 2009-09-10 20:04:38.0 +0200 +++ MY-PATH/xemacs-21.5-aroehler/lisp/lisp.el 2009-09-11 09:30:32.0 +0200 @@ -155,6 +155,21 @@ (interactive p) (kill-sexp (- (or arg 1 + +;; derived stuff from GNU Emacs +(defvar beginning-of-defun-function nil + If non-nil, function for `beginning-of-defun-raw' to call. +This is used to find the beginning of the defun instead of using the +normal recipe (see `beginning-of-defun'). Modes can define this +if defining `defun-prompt-regexp' is not sufficient to handle the mode's +needs.) + +(defvar end-of-defun-function nil + If non-nil, function for `end-of-defun' to call. +This is used to find the end of the defun instead of using the normal +recipe (see `end-of-defun'). Modes can define this if the +normal method is not appropriate.) + (defun beginning-of-defun (optional arg) Move backward to the beginning of a defun. With argument, do it that many times. Negative arg -N @@ -175,13 +190,17 @@ This is identical to beginning-of-defun, except that point does not move to the beginning of the line when `defun-prompt-regexp' is non-nil. (interactive p) - (and arg ( arg 0) (not (eobp)) (forward-char 1)) - (and (re-search-backward (if defun-prompt-regexp - (concat ^\\s(\\| - \\( defun-prompt-regexp \\)\\s() - ^\\s() - nil 'move (or arg 1)) - (progn (goto-char (1- (match-end 0 t)) + ;; (and arg ( arg 0) (not (eobp)) (forward-char 1)) + (unless arg (setq arg 1)) + (cond + (beginning-of-defun-function +(funcall beginning-of-defun-function arg)) + (t (re-search-backward (if defun-prompt-regexp + (concat ^\\s(\\| + \\( defun-prompt-regexp \\)\\s() +^\\s() + nil 'move (or arg 1)) + (progn (goto-char (1- (match-end 0 t))) ;; XEmacs change (optional buffer parameter) (defun buffer-end (arg optional buffer) @@ -198,6 +217,10 @@ ;; XEmacs change (for zmacs regions) (interactive _p) (if (or (null arg) (= arg 0)) (setq arg 1)) + (if end-of-defun-function + (if ( arg 0) + (dotimes (i arg) + (funcall end-of-defun-function))) (let ((first t)) (while (and ( arg 0) ( (point) (point-max))) (let ((pos (point))) ; XEmacs -- remove unused npos. @@ -229,7 +252,7 @@ (if (looking-at \\s\\|\n) (forward-line 1))) (goto-char (point-min) - (setq arg (1+ arg) + (setq arg (1+ arg)) (defun mark-defun () Put mark at end of this defun, point at beginning. ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] triple-quoted-string bug fixed (3)
Hi, as it turns out, assumed fix was wrong as far it concerns XEmacs. Change only works for GNU Emacs. Will see. Cheers Andreas -- https://code.launchpad.net/s-x-emacs-werkstatt/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] looking for a discussion of things python(-mode) ish
Barry Warsaw wrote: On Sep 9, 2009, at 5:56 AM, Andreas Roehler wrote: checking for the triple-quoted-bug: with python.el, (nth 8 (syntax-ppss)) shows the correct result. Unfortunately with python-mode.el (nth 8 (syntax-ppss)) fails. From there I assume, setting the syntax-table properly might solve the bug I haven't looked at this stuff in ages. Has the syntax table grown more support for the kind of things Python's triple quoted strings needs? -Barry Hi Barry, after (put-text-property TRIPLE-QUOTE-START-LAST-CHAR-POS TRIPLE-QUOTE-END-FIRST-CHAR-POS 'py-mode-syntax-table '(15 . 34)) doublequotes may be inserted inside triple quoted string - no fontification-bug then. Similar thing in python.el AFAIU. Strange thing I don't understand in context with checks inside triple quoted string (TQS): text-properties-at - (face font-lock-string-face py-mode-syntax-table (15 . 34) fontified t) But (syntax-after pos) inside returns different syntax-classes, (7) or (2) Does it query an underlying syntax-table? Below my test-text.py, triple quoted string starts at pos 330 Used (put-text-property 330 347 'py-mode-syntax-table '(15 . 34)) Probably the right thing is: (put-text-property (copy-marker 330) (copy-marker 347) 'py-mode-syntax-table '(15 . 34)) Cheers Andreas ;; #! /usr/bin/env python # -*- coding: utf-8 -*- import re, sys, os, pdb, random, time import MySQLdb from urllib2 import Request, urlopen, URLError, HTTPError # Get the command line arguments args = sys.argv # pdb.set_trace() # Get the name of the file to count the words in filename = args[1] def usage(): print Usage: %s % ( os.path.basename(sys.argv[0])) def main(): if len(sys.argv)==1: usage() sys.exit() if __name__==__main__: main() ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] triple-quoted-string bug fixed
Hi Barry,
diff attached against latest python-mode.el solves bug
328790, the triple string bug for me - checked
with X- and GNU Emacs.
Took some stuff from python.el, thanks towards its
excellent author BTW.
Did create a branch for it. Log now reads
revno: 352
committer: Andreas Roehler andreas.roeh...@online.de
branch nick: python-mode
timestamp: Thu 2009-09-10 13:30:24 +0200
message:
--fixes=lp:328790
Should I try
bzr push lp:~a-roehler/python-mode/triple-quoted-string-bug-328790.el
?
Cheers
Andreas
11a12
387a389,468
;; 2009-09-10 a.roeh...@web.de changed section start
;; from python.el, version 22.1
(defconst python-font-lock-syntactic-keywords
;; Make outer chars of matching triple-quote sequences into generic
;; string delimiters. Fixme: Is there a better way?
;; First avoid a sequence preceded by an odd number of backslashes.
`((,(rx (not (any ?\\))
?\\ (* (and ?\\ ?\\))
(group (syntax string-quote))
(backref 1)
(group (backref 1)))
(2 ,(string-to-syntax \))) ; dummy
(,(rx (group (optional (any uUrR))) ; prefix gets syntax property
(optional (any rR)) ; possible second prefix
(group (syntax string-quote)) ; maybe gets property
(backref 2) ; per first quote
(group (backref 2))) ; maybe gets property
(1 (python-quote-syntax 1))
(2 (python-quote-syntax 2))
(3 (python-quote-syntax 3)))
;; This doesn't really help.
;;; (,(rx (and ?\\ (group ?\n))) (1 ))
))
(defun python-quote-syntax (n)
Put `syntax-table' property correctly on triple quote.
Used for syntactic keywords. N is the match number (1, 2 or 3).
;; Given a triple quote, we have to check the context to know
;; whether this is an opening or closing triple or whether it's
;; quoted anyhow, and should be ignored. (For that we need to do
;; the same job as `syntax-ppss' to be correct and it seems to be OK
;; to use it here despite initial worries.) We also have to sort
;; out a possible prefix -- well, we don't _have_ to, but I think it
;; should be treated as part of the string.
;; Test cases:
;; urar x='' #
;; x = ''' ' a
;; '''
;; x '' x \ x
(save-excursion
(goto-char (match-beginning 0))
(cond
;; Consider property for the last char if in a fenced string.
((= n 3)
(let* ((font-lock-syntactic-keywords nil)
(syntax (syntax-ppss)))
(when (eq t (nth 3 syntax)) ; after unclosed fence
(goto-char (nth 8 syntax)) ; fence position
(skip-chars-forward uUrR) ; skip any prefix
;; Is it a matching sequence?
(if (eq (char-after) (char-after (match-beginning 2)))
(eval-when-compile (string-to-syntax |))
;; Consider property for initial char, accounting for prefixes.
((or (and (= n 2) ; leading quote (not prefix)
(= (match-beginning 1) (match-end 1))) ; prefix is null
(and (= n 1) ; prefix
(/= (match-beginning 1) (match-end 1 ; non-empty
(let ((font-lock-syntactic-keywords nil))
(unless (eq 'string (syntax-ppss-context (syntax-ppss)))
(eval-when-compile (string-to-syntax |)
;; Otherwise (we're in a non-matching string) the property is
;; nil, which is OK.
)))
(defsubst python-in-string/comment ()
Return non-nil if point is in a Python literal (a comment or string).
;; We don't need to save the match data.
(nth 8 (syntax-ppss)))
(defconst python-space-backslash-table
(let ((table (copy-syntax-table py-mode-syntax-table)))
(modify-syntax-entry ?\\ table)
table)
`python-mode-syntax-table' with backslash given whitespace syntax.)
;; 2009-09-10 a.roeh...@web.de changed section end
508d588
(put 'python-mode 'font-lock-defaults '(python-font-lock-keywords))
730,771c810,875
(defvar py-mode-syntax-table nil
Syntax table used in `python-mode' buffers.)
(when (not py-mode-syntax-table)
(setq py-mode-syntax-table (make-syntax-table))
(modify-syntax-entry ?\( () py-mode-syntax-table)
(modify-syntax-entry ?\) )( py-mode-syntax-table)
(modify-syntax-entry ?\[ (] py-mode-syntax-table)
(modify-syntax-entry ?\] )[ py-mode-syntax-table)
(modify-syntax-entry ?\{ (} py-mode-syntax-table)
(modify-syntax-entry ?\} ){ py-mode-syntax-table)
;; Add operator symbols misassigned in the std table
(modify-syntax-entry ?\$ . py-mode-syntax-table)
(modify-syntax-entry ?\% . py-mode-syntax-table)
(modify-syntax-entry ?\ . py-mode-syntax-table)
(modify-syntax-entry ?\* . py-mode-syntax-table)
(modify-syntax-entry ?\+ . py-mode-syntax-table)
(modify-syntax-entry ?\- . py-mode-syntax-table)
(modify-syntax-entry ?\/ . py-mode-syntax-table)
(modify-syntax-entry ?\ . py-mode-syntax-table)
(modify-syntax-entry ?\= . py-mode-syntax-table)
(modify-syntax-entry ?\ . py-mode-syntax-table)
(modify-syntax-entry ?\| . py-mode-syntax-table)
;; For historical reasons, underscore
[Python-mode] triple-quoted-string bug fixed (2)
Hi,
had to move `py-mode-syntax-table' still upward in file.
Now no complaining any more.
Thanks being patient...
Andreas
11a12
387a389,487
;; 2009-09-10 a.roeh...@web.de changed section start
;; from python.el, version 22.1
(defconst python-font-lock-syntactic-keywords
;; Make outer chars of matching triple-quote sequences into generic
;; string delimiters. Fixme: Is there a better way?
;; First avoid a sequence preceded by an odd number of backslashes.
`((,(rx (not (any ?\\))
?\\ (* (and ?\\ ?\\))
(group (syntax string-quote))
(backref 1)
(group (backref 1)))
(2 ,(string-to-syntax \))) ; dummy
(,(rx (group (optional (any uUrR))) ; prefix gets syntax property
(optional (any rR)) ; possible second prefix
(group (syntax string-quote)) ; maybe gets property
(backref 2) ; per first quote
(group (backref 2))) ; maybe gets property
(1 (python-quote-syntax 1))
(2 (python-quote-syntax 2))
(3 (python-quote-syntax 3)))
;; This doesn't really help.
;;; (,(rx (and ?\\ (group ?\n))) (1 ))
))
(defun python-quote-syntax (n)
Put `syntax-table' property correctly on triple quote.
Used for syntactic keywords. N is the match number (1, 2 or 3).
;; Given a triple quote, we have to check the context to know
;; whether this is an opening or closing triple or whether it's
;; quoted anyhow, and should be ignored. (For that we need to do
;; the same job as `syntax-ppss' to be correct and it seems to be OK
;; to use it here despite initial worries.) We also have to sort
;; out a possible prefix -- well, we don't _have_ to, but I think it
;; should be treated as part of the string.
;; Test cases:
;; urar x='' #
;; x = ''' ' a
;; '''
;; x '' x \ x
(save-excursion
(goto-char (match-beginning 0))
(cond
;; Consider property for the last char if in a fenced string.
((= n 3)
(let* ((font-lock-syntactic-keywords nil)
(syntax (syntax-ppss)))
(when (eq t (nth 3 syntax)) ; after unclosed fence
(goto-char (nth 8 syntax)) ; fence position
(skip-chars-forward uUrR) ; skip any prefix
;; Is it a matching sequence?
(if (eq (char-after) (char-after (match-beginning 2)))
(eval-when-compile (string-to-syntax |))
;; Consider property for initial char, accounting for prefixes.
((or (and (= n 2) ; leading quote (not prefix)
(= (match-beginning 1) (match-end 1))) ; prefix is null
(and (= n 1) ; prefix
(/= (match-beginning 1) (match-end 1 ; non-empty
(let ((font-lock-syntactic-keywords nil))
(unless (eq 'string (syntax-ppss-context (syntax-ppss)))
(eval-when-compile (string-to-syntax |)
;; Otherwise (we're in a non-matching string) the property is
;; nil, which is OK.
)))
(defvar py-mode-syntax-table
(let ((table (make-syntax-table)))
;; Give punctuation syntax to ASCII that normally has symbol
;; syntax or has word syntax and isn't a letter.
(let ((symbol (string-to-syntax _))
(sst (standard-syntax-table)))
(dotimes (i 128)
(unless (= i ?_)
(if (equal symbol (aref sst i))
(modify-syntax-entry i . table)
(modify-syntax-entry ?$ . table)
(modify-syntax-entry ?% . table)
;; exceptions
(modify-syntax-entry ?# table)
(modify-syntax-entry ?\n table)
(modify-syntax-entry ?' \ table)
(modify-syntax-entry ?` $ table)
table))
(defsubst python-in-string/comment ()
Return non-nil if point is in a Python literal (a comment or string).
;; We don't need to save the match data.
(nth 8 (syntax-ppss)))
(defconst python-space-backslash-table
(let ((table (copy-syntax-table py-mode-syntax-table)))
(modify-syntax-entry ?\\ table)
table)
`python-mode-syntax-table' with backslash given whitespace syntax.)
;; 2009-09-10 a.roeh...@web.de changed section end
508d607
(put 'python-mode 'font-lock-defaults '(python-font-lock-keywords))
730,771c829,875
(defvar py-mode-syntax-table nil
Syntax table used in `python-mode' buffers.)
(when (not py-mode-syntax-table)
(setq py-mode-syntax-table (make-syntax-table))
(modify-syntax-entry ?\( () py-mode-syntax-table)
(modify-syntax-entry ?\) )( py-mode-syntax-table)
(modify-syntax-entry ?\[ (] py-mode-syntax-table)
(modify-syntax-entry ?\] )[ py-mode-syntax-table)
(modify-syntax-entry ?\{ (} py-mode-syntax-table)
(modify-syntax-entry ?\} ){ py-mode-syntax-table)
;; Add operator symbols misassigned in the std table
(modify-syntax-entry ?\$ . py-mode-syntax-table)
(modify-syntax-entry ?\% . py-mode-syntax-table)
(modify-syntax-entry ?\ . py-mode-syntax-table)
(modify-syntax-entry ?\* . py-mode-syntax-table)
(modify-syntax-entry ?\+ . py-mode-syntax-table)
(modify-syntax-entry ?\- . py-mode-syntax-table)
(modify-syntax-entry ?\/ . py-mode-syntax-table)
Re: [Python-mode] looking for a discussion of things python(-mode) ish
Barry Warsaw wrote: On Sep 8, 2009, at 4:43 AM, Rohan Nicholls wrote: I checked out the python-mode launchpad project, and am now sending an email. Do I need to sign up to the python mailing list to see any discussions? Or does this email get me added to some secret list? ;) While I approved your message, you should explicitly join here http://mail.python.org/mailman/listinfo/python-mode I am very interested in getting everything under one roof, although the discussion I read in January seems to indicate that this will never be. Just to sum up reasons that I had started using python.el - python-mode had shown no sign of life for about 5 years That's changed now. - The killer was the triple quote bug. I was horribly stung by this, and at that point tossed python-mode even though the integration with ipython.el is hard to beat. I personally am rarely enough bitten by this to care, but I would love to have someone port python.el's approach to python-mode.el. IIRC, python.el uses regexps and python-mode.el uses the syntax table. Hi, checking for the triple-quoted-bug: with python.el, (nth 8 (syntax-ppss)) shows the correct result. Unfortunately with python-mode.el (nth 8 (syntax-ppss)) fails. From there I assume, setting the syntax-table properly might solve the bug Cheers Andreas The syntax table has the advantage of being much faster, which mattered a lot at one time, but it's not flexibly enough to handle Python's quoting rules. - I am an emacs user, having given up on xemacs a couple of years ago, and it shows no sign of improving, so emacs specificity is not a problem for me, in fact it is a plus, as the various incompatible bits of the two systems do not start clogging up the code. python-mode.el works just fine in both Emacs and XEmacs. So my questions are: - Is the triple quote threat solved in python-mode (because it is in python.el) I don't believe it has ever been ported over. - It seems development has started up again, would this be correct, and is there a list of things to fix somewhere? Also has Beverley Eyre compiled that list of features she mentioned back in January? Yes, it's being actively developed, but my sense of it is that python-mode.el pretty much works well for everyone using it, so I wouldn't say there's a ton of itches that need scratching. We add support for new syntax every time a new Python version comes out. It's probably not as Python 3.x friendly as it should be. -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] [Merge] lp:~freiksenet/python-mode/hide-show-support into lp:python-mode
Mikhail Novikov wrote: Mikhail Novikov has proposed merging lp:~freiksenet/python-mode/hide-show-support into lp:python-mode. Requested reviews: python-mode.el developers (python-mode-devs) I have improved it to support more constructs and docstrings. Works fine for me, more testing is needed. Some versions of emacs introduced bug to hideshow that makes this work badly. Hideshow.el from emacs trunk works fine. Hideshowviz.el conflicts with python-mode because it implements own mod-map. To fix it comment out mode-map enable line in hideshowviz mode enable and add global keybinding hooked to hs-minor-mode to get the keybinding introduced in hideshowviz back. Hi Mikhail, seeing you changed regexp inside `hs-special-modes-alist': good idea IMO, works fine. Nonetheless let's raise some questions: Concerning `hs-block-start-regexp': people may have different opinions what to hide. What about to make this customizable? After this: do you need (unless (assoc 'python-mode hs-special-modes-alist) I.e. why not set the value always if python-mode is called? Cheers Andreas -- https://code.launchpad.net/s-x-emacs-werkstatt/ http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] What text editor is everyone using for Python
Rhodri James wrote: On Wed, 27 May 2009 16:56:12 +0100, Bruno Desthuilliers bruno.42.desthuilli...@websiteburo.invalid wrote: Rhodri James a écrit : On Tue, 26 May 2009 14:22:29 +0100, Roy Smith r...@panix.com wrote: My pet peeve is syntax-aware editors which get things wrong. For example, the version of emacs I'm using now doesn't parse this properly: '''A triple-quoted string. Some editors won't get this right''' The solution is to change the outer quotes to double-quotes, but it annoys me when I have to change my code to appease a tool. It's the separate python-mode that gets this (and much else) wrong. The Python mode that Ubuntu packages with emacs 22.2.1 works just fine. On this point, indeed. But it also lacks almost every nice feature of the One True python-mode (or at least did last time I had to update this ... ubuntu box at work). That rather depends on your definition of nice. The only feature of python-mode.el that I miss in python.el is the ability to run pylint from the menu, Thanks mentioning it, I'll cc this to python-mode@python.org and I'll get over that. The feature that caused me to uninstall python-mode.el was its bloody-minded determination to regard '_' as a word character, something which caused me more typing that it ever saved. Its just one line to comment in python-mode.el, like this: ;; (modify-syntax-entry ?\_ w py-mode-syntax-table) ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] pdbtrack
ken manheimer wrote: looking at this a little bit more closely, it's surprising to me not that it fails for you, but that it works at all. Hi Ken, thats the point probably. Originally question was: must we change the source-code in order to make pdbtrack working, must we put a pdb.set_trace() into it? Tried to avoid that and watched results coming from pdb also without that. While executing, results are delivered to function py-pdbtrack-get-source-buffer (block) line 1444 of my python-mode.el Then (string-match py-pdbtrack-stack-entry-regexp block) decides to accept result or not. Played a little bit with py-pdbtrack-stack-entry-regexp:. ;; pdbtrack constants (defconst py-pdbtrack-stack-entry-regexp ; ^ \\([^(]+\\)(\\([0-9]+\\))\\([?a-zA-Z0-9_]+\\)() ;; ^ \\(.*\\)(\\([0-9]+\\))\\([?a-zA-Z0-9_]+\\)() \\(.*\\)(\\([0-9]+\\))\\(.*\\)() ;; ^ \\(.*\\) Regular expression pdbtrack uses to find a stack trace entry.) Andreas have you made any changes to the py-pdbtrack-input-prompt variable (aka 'python-pdbtrack-input-prompt' in recent versions of python.el)? as the docstring for py-pdbtrack-track-stack-file states, We depend on the pdb input prompt matching `py-pdbtrack-input-prompt' at the beginning of the line. the default setting simply should not match the ipydb that your photos are showing. ? sorry if i'm missing something obvious - i'm trying to get context here, with not quite enough time to pay full attention... -- ken http://myriadicity.net http://myriadicity.net/ On Fri, May 1, 2009 at 5:28 PM, ken manheimer ken.manhei...@gmail.com mailto:ken.manhei...@gmail.com wrote: On Fri, May 1, 2009 at 4:50 PM, Andreas Roehler andreas.roeh...@online.de mailto:andreas.roeh...@online.de wrote: Barry Warsaw wrote: On Apr 30, 2009, at 4:07 PM, Andreas Roehler wrote: I'll send you two screenshots offlist. Please feel free to forward them to interested persons, just didn't want to publish my path at the list. 20090428_pdbtrack3.png displays pdbtrack opened second windows, cursor displayed at line 4 import With 20090428_pdbtrack4.png you see shell-output from line 8, but cursor in second window still is at line 4. Always get Traceback cue not found Cause seems var `py-pdbtrack-stack-entry-regexp'. That doesn't happen, if pdb.set_trace() is inside the python-file. Did someone else remark this? Hi Andreas, I haven't heard this one before, but perhaps it's because of the ipython prompt? Maybe. As shows message in first screenshot #3, pdbtrack indicates line 4 correctly. Its not brocken completely. i'm having some difficulties tracking your descriptions of the situation, andreas, but i think you (and barry) are right that the problem is failure to recognize, rather than pdbtrack not being activated (as you seemed to initially be suggesting). Its a question of regexp, which doesn't recognise/accept the result, delivered by `block'. i don't understand what you mean by delivered by 'block' Already tried to change the regexp or even simply eliminate that checking step, but not found a solution. the match may be necessary to parse the traceback, and for other reasons. Hhm. Could you give me an example, how you run script activating pdbtrace, reaching the standard (pdb) prompt from Emacs? what do you mean by reaching the standard (pdb) prompt from Emacs?? perhaps you're talking about the python interaction buffer that python-mode provides? i believe, but am not certain, that pdbtrack watches the output in any comint buffer, including the python interaction buffer. i can check this kind of thing, but need to understand better what you're saying before investigating. Only get it from shell. one thing i can suggest that you do is copy the text from the emacs buffer that pdbtrack should recognize but doesn't, and send that excerpt to us. i know that's in the pictures, but it's easier for you to send us the text than it is for us to type it accurately from the pictures.-) preferably you would also send an excerpt that is similar but is successfuly recognized. i will try to find time to examine it, and see if i can identify what is happening and what should be happening... -- ken http://myriadicity.net Thanks Andreas I think pdbtrack expects (by default) the standard (pdb) prompt. -Barry ___ Python-mode mailing list Python
Re: [Python-mode] pdbtrack
Barry Warsaw wrote: On Apr 30, 2009, at 4:07 PM, Andreas Roehler wrote: I'll send you two screenshots offlist. Please feel free to forward them to interested persons, just didn't want to publish my path at the list. 20090428_pdbtrack3.png displays pdbtrack opened second windows, cursor displayed at line 4 import With 20090428_pdbtrack4.png you see shell-output from line 8, but cursor in second window still is at line 4. Always get Traceback cue not found Cause seems var `py-pdbtrack-stack-entry-regexp'. That doesn't happen, if pdb.set_trace() is inside the python-file. Did someone else remark this? Hi Andreas, I haven't heard this one before, but perhaps it's because of the ipython prompt? Maybe. As shows message in first screenshot #3, pdbtrack indicates line 4 correctly. Its not brocken completely. Its a question of regexp, which doesn't recognise/accept the result, delivered by `block'. Already tried to change the regexp or even simply eliminate that checking step, but not found a solution. Hhm. Could you give me an example, how you run script activating pdbtrace, reaching the standard (pdb) prompt from Emacs? Only get it from shell. Thanks Andreas I think pdbtrack expects (by default) the standard (pdb) prompt. -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] pdbtrack
Hi Barry, I'll send you two screenshots offlist. Please feel free to forward them to interested persons, just didn't want to publish my path at the list. 20090428_pdbtrack3.png displays pdbtrack opened second windows, cursor displayed at line 4 import With 20090428_pdbtrack4.png you see shell-output from line 8, but cursor in second window still is at line 4. Always get Traceback cue not found Cause seems var `py-pdbtrack-stack-entry-regexp'. That doesn't happen, if pdb.set_trace() is inside the python-file. Did someone else remark this? Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] bugfixes, `py-match-paren' now at %
Yaroslav Halchenko wrote: pardon my ignorance, but was it done on purpose? in 356. By Andreas Roehler on 2009-01-29 ,--- | *$ git show 07985672d238301b27353913fc4aa509992571fb --stat | commit 07985672d238301b27353913fc4aa509992571fb | Author: Andreas Roehler andreas.roeh...@online.de | Date: Thu Jan 29 18:33:20 2009 +0100 | | py-match-paren | | README |7 - | doctest-mode.el | 2061 --- | pycomplete.el | 50 -- | pycomplete.py | 110 --- | python-mode.el | 86 +++ | 5 files changed, 86 insertions(+), 2228 deletions(-) `--- you've removed all those files in the root of the repository and left only python-mode (which you also modified in the same commit) and the website directory log message (py-match-paren) is too concise to figure out what was intended ;-) P.S. git-bzr is cool -- now I can watch both branches (main and yours) in the same git repository ;-) On Wed, 04 Feb 2009, Andreas Roehler wrote: Hi, luckily announce some progress in python-mode.el (branch) `py-match-paren' now has a key: % as in lisp. `M-x py-match-paren-mode', jump between beg and end of block pressing %. To the beginning first, if inside. Hi Yaroslav, as Barry seems busy, are you able to combine pyton-mode.el from branch with remaining files from trunk? BTW as branch changes still, please tell about your deadlines, if you want to build it in. No bugs concerning my changing known so far. Thanks Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] bugfixes, `py-match-paren' now at %
Yaroslav Halchenko wrote: as Barry seems busy, are you able to combine pyton-mode.el from branch with remaining files from trunk? well -- now -- not natively since if I merge your branch I loose those removed files: $ git merge bzr/a-roehler Merging HEAD with bzr/a-roehler Removed README Removed doctest-mode.el Removed pycomplete.el Removed pycomplete.py Auto-merged python-mode.el may be in bzr there is a native way to handle merges on per-file basis but unfortunately I am not familiar with bzr. I can always though generate a patch of your modifications in python-mode and apply within my local copy of the master branch, but that is not native way and brings even more confusion. It might be that if you added those files back, bzr would be able to handle situation gracefully... OK. I'll try that. Have not that much experience with bazaar too... I'll wait some days still, maybe Barry has another idea. Cheers Andreas git does apparently: So, I've added those files back within a local copy of your branch and then tried to merge your branch back into the master *$ git merge a-roehler Merging HEAD with a-roehler Auto-merged python-mode.el Merge made by recursive. python-mode.el | 374 1 files changed, 349 insertions(+), 25 deletions(-) BTW as branch changes still, please tell about your deadlines, if you want to build it in. I am just a little person -- a maintainer of python-mode.el for Debian. I've already shipped current version into Debian, and would be happy to ship a new version with your modifications if they propagate reach master branch No bugs concerning my changing known so far. nothing is good than a real field testing by hunders of users -- unexpected aspects of code functioning get unraveled ;-) ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] SF tracker import
Barry Warsaw wrote: On Feb 4, 2009, at 11:05 AM, Yaroslav Halchenko wrote: I myself (since new to python-mode list and development in general) can't provide any objective information, besides that imported list looks great to me ;) unfortunately that bugs.staging.launchpad.net doesn't like me, so I was able to lookup only few bugs before I start getting Sorry, there was a problem connecting to the Launchpad server. ;-) staging is a test server so besides getting wiped nightly, it's sometimes flaky as we bring it up and down to test things for production. as soon as migration happens I will try to 'connect' left-out bug reports in Debian to your bug tracking http://bugs.debian.org/python-mode Thanks! Barry ___ Me too got: The requested URL could not be retrieved Well as you said: test server. So we look forward. Thanks so far Andreas ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] replacing python.el
Barry Warsaw wrote: On Feb 1, 2009, at 10:42 AM, Jeff Kowalczyk wrote: On Sun, 01 Feb 2009 07:33:15 -0500, Barry Warsaw wrote: As Andreas pointed out, we have not yet merged his changes into python- mode.el. I had hoped that it would be possible to merge python-mode.el and python.el and reduce the confusion and inconvenience of Python X/Emacs users. Andreas's opinion is that that is technically impossible and I believe it is Dave's opinion that it will be practically impossible from a legal perspective. 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? I will defer to Andreas and Bev since they've looked at this issue most closely. Barry Ahh Barry, you are really a wise man. I'm looking forward for some funny days. :) Hi Jeff, we had a lot of traffic around this question last days: maybe let the course of events giving the answer? Beverley has declared its interest, from which I expect in any case knowledge return for all of us. My interest is compatibility, which can be reached by different means. So let's go back to coding and see what comes out. OK? Andreas Röhler -- http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/files https://code.launchpad.net/s-x-emacs-werkstatt/ ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] FSF assignment policy
Dave Love wrote: Andreas Roehler andreas.roeh...@online.de writes: Barry Warsaw wrote: For this audience, I'll restate my position, vis-à-vis python-mode. I assert that Tim Peters and myself have assigned copyright in python-mode.el to the FSF. For this audience, again: Unfortunately the FSF only has an assignment from Tim Peters, and when I tried to get one from Barry some years go, the problem was that it needed papers from his employer. (Several of us had tried to get full paperwork for python-mode.el, maybe including rms. The authorship of all the code wasn't clear at that stage, so it may not have been profitable anyway. I've no doubt that Barry wants to DTRT in this respect, and I wouldn't have spent the effort on separate code if it looked as if we had a reasonable chance of complete paperwork. IMO assignment policy contradicts the spirit of free software. It shows very unpleasant damages in mind already. Copyright is an important issue now, taken very seriously. Before code was exchanged freely, as Richard told nicely the very beginnings of the movement. Meanwhile we came to the opposite: jealously and meticulous line counting habits. Assignment stifles cooperation rather then being helpful. If the employer isn't now a problem, maybe an assignment for future contributions would be useful.) I want it to be possible from a legal standpoint to merge python-mode.el and python.el, taking the best and most popular features and functionality from each. I think python-mode.el should form the basis of the merge, with code pulled in from python.el as needed. Current maintainers may disagree, but I don't think popularity with Python programmers trumps the Emacs coding conventions. Still, the only missing things I've heard of either violate the conventions or aren't specific to Python and should be elsewhere, or already are. Difference is not at the level of feature-function, but from the very beginning. It's a little bit the same as with GNU and XEmacs: you can't merge with reasonable cost and result now. Yes, this follows what's mostly happened with XEmacs historically. It's not a question of merging now, though -- this was all long ago. From this some chances too: Not every feature once implemented turns out useful. Not every feature is needed by everyone. After working with and on python-mode.el, I did take the opportunity to try to write something clean without undue mis-features. That was a general remark, in no way aimed at your code. Let me take the opportunity to assert you: I'm well respecting the work. My offer was and is: let's cooperate. There are enough things to do beside pure code-writing. Nor should the assignment nor the GPL-versions-question block cooperation completely. We must respect hindrances as it exists, that's right. I would welcome a friendly, sportive concurrence. So if Dave may tell, what's the point of python.el is in contrast to python-mode.el, I'm interested to read. We wanted decent Python support for and in Emacs. There's commentary in the file, although it may not be complete. ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] FSF assignment policy
Barry Warsaw wrote: On Jan 27, 2009, at 4:08 AM, Andreas Roehler wrote: as FSF assignment policy was raised again at python-mode@python.org, please permit to ask you a thing I never understood: AFAIS every Emacs-file is inspired by many, many others from the very beginning. We see almost always a plenty of revisions with a lot of people involved. So how a single developer could ever declare what the assignment formula demands? How could any person declare, he _owns_ the rights at the code, thus assigning it. Isn't that assignment policy driving developers in a kind of forgery? Making them false declarations, thus having rights about them, being everyday able to sue them for these false declarations? Or am I simply dreaming a bad dream? For this audience, I'll restate my position, vis-à-vis python-mode. I assert that Tim Peters and myself have assigned copyright in python-mode.el to the FSF. I believe that Ken Manheimer has done the same, and I believe that Skip Montanaro has tried to do so several times in the past. This should cover the majority if not the entirety of the current python-mode.el file. I want it to be possible from a legal standpoint to merge python-mode.el and python.el, taking the best and most popular features and functionality from each. I think python-mode.el should form the basis of the merge, with code pulled in from python.el as needed. Andreas has the current momentum pumpkin for working on python-mode.el, so I want to find a way for him to do this while still retaining the ability to merge the two modes. Note that Andreas, AFAIK has not volunteered to do this merge, although others on the python-mode@python.org mailing list have expressed interest. If Andreas is unwilling to assign copyright to the FSF, then perhaps some other mechanism will be acceptable to him and to the FSF. Please explore this possibility. Thanks Barry Hi Barry, thanks a lot investing that much care in the matter. For me --due to FSF assignment -- XEmacs represents much more the principle of four freedoms than GNU Emacs now. Incidentally that's the reason I changed my focus from GNU to X. So originally a pure political change, I'm not unhappy now. And yes: XEm looks nicer... :) Concerning the intended merge, let me say it again: IMO its technically impossible. As Dave wrote: proceeding differs profoundly and deliberately. We have two different modes now which implement respective features in a different way. Difference is not at the level of feature-function, but from the very beginning. It's a little bit the same as with GNU and XEmacs: you can't merge with reasonable cost and result now. From this some chances too: Not every feature once implemented turns out useful. Not every feature is needed by everyone. I would welcome a friendly, sportive concurrence. So if Dave may tell, what's the point of python.el is in contrast to python-mode.el, I'm interested to read. Maybe we should consider development as a kind of climbing: at least one team must get the peak. From the users perspective --which should be the final measure-- it doesn't matter which team wins. Back to politics: As we have a GNU backed python.el, it seems reasonable to proceed --waving the flag of freedom :)-- with a XEmacs associated python-mode.el. Thanks all Andreas Röhler ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] FSF assignment policy
Stephen J. Turnbull wrote: I am not a lawyer, and I don't speak for the FSF or the Emacs Project. I do speak for the XEmacs Project until such time as someone feels like complaining about it. :-) Andreas Roehler writes: as FSF assignment policy was raised again at python-mode@python.org, please permit to ask you a thing I never understood: AFAIS every Emacs-file is inspired by many, many others from the very beginning. We see almost always a plenty of revisions with a lot of people involved. AIUI, this is one of the motivations for the free software movement: each program created is a joint creation of the apparent author(s), and of the community around them. (I'm pretty sure Richard would say it's not the most important motivation, but I suppose he will acknowledge it.) Nevertheless, software *also* exists in a legal environment, and the assignment policy (like the GPL) is a compromise between the *goal* of software freedom and the *limited means* provided[1] by that legal system for implementing software freedom. So how a single developer could ever declare what the assignment formula demands? How could any person declare, he _owns_ the rights at the code, thus assigning it. For starters, he doesn't make such a declaration about the code. He makes that declaration about his own contribution. The way he acquires that power is simple: he writes some code down. That's all it takes! Whether he publishes or not. Then, according to the Berne Convention and other applicable treaties, he is automatically awarded such copyright privileges as are created by the law of each jurisdiction in which the software is available. Exactly what privileges he is awarded are determined by the local laws, and which parts of the software are his are determined in principle by the law, and in practice by a court if his claims are contested. In other words, the question you are asking is not posed by the assignment policy, but rather by the very existence of copyright itself. The assignment policy, then, is one of an array of policies (including advocacy of copyleft licenses, for example) adopted by the free software movement to preserve software freedom, in the context of such a legal system. Isn't that assignment policy driving developers in a kind of forgery? Making them false declarations, thus having rights about them, being everyday able to sue them for these false declarations? No. There is no forgery, assuming you make the claim in good faith. You may still be liable for infringement if you are mistaken about the extent of your rights, just as you may be liable for an automobile accident if the car in front of you stops without warning for no apparent reason and you run into it. Or am I simply dreaming a bad dream? There is no law in the U.S. or Japan about making declarations, I don't know about Europe. That is, the fact that you assign what you believe to be your code to another party does not increase your risk, per se. What matters is if you make or enable copies, or the assignee does. But for free software, the risk imposed by assignee-made copies is precisely the same as the risk imposed by GPL-licensee-made copies. In other words, if the risk involved in assigning your code bothers you, what are you doing participating in free software at all? However, the idemnity clause of the standard FSF assignment contract may increase your risk, since you're required to defend the FSF as well as yourself. Ask a lawyer if that bothers you. Note: I personally am not particularly a fan of the assignment policy, though the recent trend in many projects to adopt such a policy may force me to reconsider that position. However, the objections you seem to have in mind really apply to copyright itself, and the assignment policy is just shadowing it. Precisely. The question already touched so far is, if or how copyright might declared with respect to programs. Is copyright a useful term with respect to computer programs? I say: no. You, Steve, knows that very well. Some days ago we discussed beginning-of-defun-function. Reflection was: maybe implement it differently then GNU function. Why not, no matter. Now, can you implement a poem from --say-- Allan Ginsberg differently then Ginsberg did? You can't. And that's the different between the realm, where copyright makes some sense and where it's nonsense. You may be condemed for nonsense, wars are declared for nonsense, yes. Nonsense is a real existing force. But let's consider another aspect of dangers I see coming: Copyright always was and is a weapon to witheld things. It might turn into a terrible weapon with computers, if people depend on them. That's why giving it free is ok and best. Then copyright is no longer a danger. So why collect, harbour and even monopolize things, you want to be free? AFAIS the reason is the gain of power
Re: [Python-mode] py-block-at-point and other reporting functions
Barry Warsaw wrote: On Jan 26, 2009, at 9:56 AM, Andreas Roehler wrote: some new functions are available: py-beginning-of-def-or-class py-class-at-point py-function-at-point py-beginning-of-function py-beginning-of-class py-end-of-function py-end-of-class py-end-of-def-or-class py-line-at-point py-block-at-point py-beginning-of-block py-end-of-block Compound reports returning buffer-strings by py-whats-at-point Made py-beginning-of-def-or-class (really or) Old behaviour is preserved with py-beginning-of-def-or-class-if-arg Hi Andreas, I'm not really going to have time to review this code any time soon. Sorry, I'm swamped. If nobody else has the time then I would say, let's use the following guidelines so that you aren't blocked (since you have the current momentum pumpkin :). Hi Barry, thanks for answering. I'm aware of you situation concerning time. If you don't change existing default behavior, you're cool. Always have that in mind. Until now there is one changing concerning py-beginning-of-def-or-class really or So far I see no other need and this one might revoked if causing divorce... :) If you're fixing a bug, you're cool. OK, but even then: the assigment question... See below. IMHO assignment blocks development to a large extent. Let us know when you commit changes and I will 'bzr pull' the new version and try it in my day-to-day editing. If there's a problem, I'll let ya know. :) But... let's be sure we get your signature on a copyright assignment to the FSF, Ahh, as told, I'm _not_ going to sign. Is XEmacs code assigned as such? Reading the code and the history of python-mode.el I assume no one is able to assign this code to FSF rightfully. so everything's legally clean. Does such a thing exist in this world? There are no more dirty corners than in lawyers and the courts houses. What I can assure: that I have written the changes I sent you. BTW in german we have a saying: Don't awake the sleeping dogs. That's just the thing, legalizing does. It's a never ending night-mare. FSF seems running into. Andreas Röhler Sound okay? Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
[Python-mode] py-beginning-of-def-or-class really or
Hi, intend to make py-beginning-of-def-or-class really or, i.e. looking for each of them. Doku says: , | Searches back for the closest preceding `def'. If you | supply a prefix arg, looks for a `class' instead. ` Presently, reaching the must upward def, you must type \C-u first, to reach the class. Afterwards it will be sufficient to repeat the command, while universal arg should be kept nonetheless. Any objections/suggestions? Andreas Röhler -- Mentioned python-mode.el branch is available at http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/files ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] py-next-statement, py-previous-statement
[...] . If, however, I am on a line with an elif it might be useful to have it back up to the preceeding elif Hi Skip, uploaded new functions forward-/backward-block It stops at every line beginning with python-keywords. Andreas Röhler Mentioned python-mode.el branch is available at http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/files or if clause instead of moving up one simple statement or clause at a time. (Just a thought.) Skip ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] agenda
Eric S. Johansson wrote: Andreas Roehler wrote: What about to implement some reporting feature, saying via message-buf for example what is closed? We could proceed in two steps: First introduce such a reporting level for all things, than make the voices side. Or should we consider something special right from the beginning? I'm afraid you've lost me. With speech recognition (what you say is what it types... mostly) I would like to try and create an environment where, based on the current cursor position, I can ask the editor certain questions such as, what method/class are you in? what type of name are you (class, variable)? if you are a class, what methods do you know about? there's something I'm not quite sure how to handle yet such as choosing from a list of objects and invoking the right argument signature. I'm not too worried though. These things usually come to me about 15 minutes too late. :-) introduced `py-close-function' and `py-close-class'. That's the kind of thing you asked first. It's useful for me too. It's available from https://code.launchpad.net/~a-roehler/python-mode/python-mode.el Andreas Röhler ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] merging python-mode.el and python.el
Barry Warsaw wrote: On Jan 18, 2009, at 4:29 PM, Dave Love wrote: There is talk in the python-mode.el and on the web site of merging it with python.el. I hope people realize that can only be done in accordance with the GPL licence of python.el -- i.e. one way -- although it doesn't seem useful anyhow. There's already been an attempt to put python.el code into python-mode.el contrary to the licence via a bug report, and I'm concerned that it doesn't happen any more (unless python-mode.el's licence is changed, obviously). It's not clear to me what's in python-mode.el that would be useful to put in python.el, although I've only skimmed the current version. Anyway the main raison d'être for python.el was that we couldn't get copyright papers for python-mode.el for inclusion in Emacs (and I won't put unassigned code in my version). Also, python-mode.el changes for Emacs weren't accepted, so I wrote an intentionally incompatible mode to minimize confusion and ease maintenance. While technically the python-mode.el file does not have GPL license on it, we've tried many times in the past to assign copyright so that it /could/ have such a license on it, and even be owned by the FSF. It's long been pulled out of the Python distribution so it needn't (and in fact doesn't) have a PSF license on it. Tim and I have both assigned copyright in our changes to the FSF. I think Ken did too, as he was the author of pdb-track among other good code in python-mode.el. I'm not sure about Skip. Looking at the committer line from 'bzr log' (which should include the svn history), that should just about cover it, though there may be contributions described in comments that need to be looked at. I believe there should be no reason why python-mode.el could not be released under the GPL, probably even with a copyright FSF. If there are a few contributors who need to be tracked down to get assignments from, that shouldn't be difficult. -Barry Hi Barry, I didn't sign code to FSF and probably will not. The reasons I already declared on FSF-list and towards RMS. Will not make it up here, unless you ask me to. As you approved my tiny peace of code, but not merged AFAIS, should I keep a separate branch on lp? Cheers Andreas Röhler ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] Unadmin myself
Stephen J. Turnbull wrote: Barry Warsaw writes: On Jan 18, 2009, at 11:47 AM, s...@pobox.com wrote: I'm going to stop pretending I'm contributing anything to python-mode development. Heh. In my book, just making an announcement that you're definitely going to be inactive in the future is a contribution! If anyone would like to step forward and maintain the XEmacs package version of python-modes, please speak up on the XEmacs development list xemacs-b...@xemacs.org. [ ... ] Hi Steve, I'm volunteering for the job. I'm not familiar with the Xemacs package system. As you wrote, it's not that crucial. Andreas Röhler ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] merging
Hi Beverley, IMO exists no easy way to merge at all here in general. Proceeding differs occasionally profoundly; results and chances are only seen partly (at least for me). So I wouldn't want to say: drop this form, take another and rebuild with that. After all the only useful way I imagine is to regard form by form starting from an real issue/feature to implement. So my question would be: Do you see any feature in python.el, python-mode.el doesn't deliver? Thanks Andreas Röhler Beverley Eyre wrote: I see that the initial emails that Barry and I exchanged are here, but not the rest. Briefly, I'm going to take on the task of comparing and analyzing python.el (GNU) and python-mode.el (Launchpad) with the idea that a merged and better-than-either version can be created, and will begin by doing the suggested inventory. To get a quick idea of the size of the task, I wrote a script that figured out how many functions there are and how many have the same name in both versions (sans the 'py-' or 'python-' prefix). There are 81 functions in python-mode.el and 66 functions in python.el, 147 total. Of those, only 9 have the same function name: py[thon]- backslash-continuation-line-p continuation-line-p current-defun guess-indent(-offset for pm) indent-line mark-block next-statement outdent-p previous-statement I haven't actually looked at them yet, so I don't know if they are identical, but in any case, it looks as if there is not a whole lot of cross-over. Anyway, I'll post more when I've made a little progress. I won't post any my analysis here because of the probable size of the files, but I'll put them in some easily downloadable spot, like the wiki maybe, and anyone interesting in participating in a code review process can get them and talk about it here. Bev Barry Warsaw wrote: On Jan 1, 2009, at 9:56 PM, Beverley Eyre wrote: I'm writing because I am interested in helping merge python.el with python-mode.el and your website suggested that I contact you. I'm happy that there is someone on Earth besides me who uses emacs to edit python code and wants a better mode. Hi Beverley, I'm psyched to hear you're interested in helping out with this. I think one of the first things to do is to inventory what's different between the two modes. Then we should try to evaluate which mode does common tasks better and decide what we'll take from each. Would you be up for that? -Barry ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
