Problem with Multi-Line Comments

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with Multi-Line Comments

Kent Borg
Hello,

I recently started playing with using docstrings more fully and
discovered a problem.  I can't use apostrophes in multi-line comments
without confusing python-mode.

For example:

> def my_sqrt(x):
>     '''Computes squareroot.
>
>     Note: This function doesn't know about imaginary numbers, to it
>     can't handle negative parameters.
>     '''

It gets all confused by the single quotes.

Am I misunderstanding something?


Thanks,

-kb
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Multi-Line Comments

Andreas Röhler-2
Kent Borg wrote:

> Hello,
>
> I recently started playing with using docstrings more fully and
> discovered a problem.  I can't use apostrophes in multi-line comments
> without confusing python-mode.
>
> For example:
>
>> def my_sqrt(x):
>>     '''Computes squareroot.
>>
>>     Note: This function doesn't know about imaginary numbers, to it
>>     can't handle negative parameters.
>>     '''
>
> It gets all confused by the single quotes.
>
> Am I misunderstanding something?
>
>
> Thanks,
>
> -kb
Hi,

sounds like a well known bug of python-mode.el.
Can reproduce it with emacs -Q.
Unfortunately not with my common environment, telling me
python-mode.el version 351 is in use. See screenshot attached.
Strange.

BTW which system/version/emacs you are using?

Andreas





_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode

tqs.png (154K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Multi-Line Comments

Skip Montanaro-3
In reply to this post by Kent Borg

    Kent> Am I misunderstanding something?

Perhaps.  There is definitely a deficiency in the Emacs syntax table stuff,
at least the way python-mode uses it.  I believe the other Python mode (the
one delivered with recent versions of GNU Emacs) might handle triple-quoted
strings better.

In many cases you can avoid the problem by using """...""" to surround
strings containing apostrophes and '''...''' to surround strings containing
quotation marks.  The only problem you encounter there is the situation
where your doc strings contain both quotation marks and apostrophes.

Skip
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Multi-Line Comments

Kent Borg
In reply to this post by Andreas Röhler-2
Andreas Roehler wrote:
> BTW which system/version/emacs you are using?

kentborg@bottom:~$ emacs --version
GNU Emacs 22.2.1
Copyright (C) 2008 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
kentborg@bottom:~$ uname -a
Linux bottom 2.6.28-17-generic #58-Ubuntu SMP Tue Dec 1 18:57:07 UTC
2009 i686 GNU/Linux
kentborg@bottom:~$ cat /etc/debian_version
5.0
kentborg@bottom:~$ cat /etc/issue
Ubuntu 9.04 \n \l



I am running Gnome under GDM, but "emacs -nw" acts the same way.

I notice that when typing that while typing the quote marks, the
highlighting seems to be simply counting open-close-open-close, etc.
(Clever that three quotes is an odd number so it looks to naive syntax
highlighting a bit like a single quote.)

Does your emacs update highlighting when you type one quote?  Does it
update it again after a second?  What does it do after a third?  And,
what does it do on the close set?

Oh, one more thing: I moved my .emacs aside to make sure it isn't the
problem...and it seems it is not.


Thanks,

-kb

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Multi-Line Comments

Kent Borg
In reply to this post by Andreas Röhler-2
Andreas Roehler wrote:
> python-mode.el version 351 is in use.

I am not using that version.  I dug around and downloaded 351.
Internally mine is versioned: "5.1.0", 351 says "5.1.0+".


kentborg@bottom:~$ diff
/usr/share/emacs/site-lisp/python-mode/python-mode.el
/home/kentborg/sw_downloads/python-mode.el
12c12
< (defconst py-version "5.1.0"
---
> (defconst py-version "5.1.0+"
2406c2406,2407
<     (indent-rigidly start end count)))
---
>     (let (deactivate-mark)
>       (indent-rigidly start end count))))
2419c2420
<          (m (mark))
---
>          (m (condition-case nil (mark) (mark-inactive nil)))
2447c2448
<          (m (mark))
---
>          (m (condition-case nil (mark) (mark-inactive nil)))


Dropping the new one in place doesn't fix it, but I think I need to
compile something...


Thanks,

-kb, the Kent who is heading off to ask Google again.

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Multi-Line Comments

Barry Warsaw
In reply to this post by Skip Montanaro-3
On Dec 11, 2009, at 8:50 AM, [hidden email] wrote:

>
>    Kent> Am I misunderstanding something?
>
> Perhaps.  There is definitely a deficiency in the Emacs syntax table stuff,
> at least the way python-mode uses it.  I believe the other Python mode (the
> one delivered with recent versions of GNU Emacs) might handle triple-quoted
> strings better.

I think python.el uses regular expressions instead of the syntax table.  I also thought there were patches to python-mode.el to make it work more closely like python.el.

> In many cases you can avoid the problem by using """...""" to surround
> strings containing apostrophes and '''...''' to surround strings containing
> quotation marks.  The only problem you encounter there is the situation
> where your doc strings contain both quotation marks and apostrophes.

Generally, if the quotes are balanced the worse that can happen is that you'll get a little run of text in a different color.  If they're not balanced though, it will mess up Emacs's syntax table logic and you'll need a little "turd" to help line things up again:

def foo():
   '''Some people don't like this.''' # ' <- Emacs turd

It would be nice to fix this.

-Barry

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Multi-Line Comments

Kent Borg
In reply to this post by Kent Borg
Kent Borg wrote:
> Dropping the new one in place doesn't fix it, but I think I need to
> compile something...

Follow up on my last e-mail...


OK, I think I compiled it:

kentborg@bottom:~$ ls -l
/usr/share/emacs/site-lisp/python-mode/python-mode.elc
-rw-r--r-- 1 root root 115028 2009-12-11 09:38
/usr/share/emacs/site-lisp/python-mode/python-mode.elc

New launch of emacs -nw still gets confused.


Thanks for everyone's patience,

-kb
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Multi-Line Comments

Barry Warsaw
In reply to this post by Kent Borg
On Dec 11, 2009, at 9:25 AM, Kent Borg wrote:

> Dropping the new one in place doesn't fix it, but I think I need to
> compile something...

FWIW, I run python-mode.el right out of a bzr checkout.  I never byte compile my personal elisp files any more. :)

-Barry

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Multi-Line Comments

Andreas Röhler-2
In reply to this post by Kent Borg
Kent Borg wrote:

> Andreas Roehler wrote:
>> BTW which system/version/emacs you are using?
>
> kentborg@bottom:~$ emacs --version
> GNU Emacs 22.2.1
> Copyright (C) 2008 Free Software Foundation, Inc.
> GNU Emacs comes with ABSOLUTELY NO WARRANTY.
> You may redistribute copies of Emacs
> under the terms of the GNU General Public License.
> For more information about these matters, see the file named COPYING.
> kentborg@bottom:~$ uname -a
> Linux bottom 2.6.28-17-generic #58-Ubuntu SMP Tue Dec 1 18:57:07 UTC
> 2009 i686 GNU/Linux
> kentborg@bottom:~$ cat /etc/debian_version
> 5.0
> kentborg@bottom:~$ cat /etc/issue
> Ubuntu 9.04 \n \l
>
>
>
> I am running Gnome under GDM, but "emacs -nw" acts the same way.
>
> I notice that when typing that while typing the quote marks, the
> highlighting seems to be simply counting open-close-open-close, etc.
> (Clever that three quotes is an odd number so it looks to naive syntax
> highlighting a bit like a single quote.)
>
> Does your emacs update highlighting when you type one quote?
Yes
 Does it
> update it again after a second?

It does it immediatly.

  What does it do after a third?  And,
> what does it do on the close set?
>
> Oh, one more thing: I moved my .emacs aside

no need for that, emacs -q or emacs -Q is the right thing then

 to make sure it isn't the
> problem...and it seems it is not.
>

When started emacs -q you should not encounter that problem - maybe others...

Already tried to tackle the issue. Works with GNU Emacs for me, not with XEmacs until now.
Introduced some stuff from python.el - defconst python-font-lock-syntactic-keywords etc.

Patch attached - not polished yet, but works here some weeks now.

Andreas


387a388,488

> ;; 2009-09-10 [hidden email] changed section start
> ;; from python.el, version "22.1"
>
> (defconst python-font-lock-syntactic-keywords
>  
> '(("[^\\]\\\\\\(?:\\\\\\\\\\)*\\(\\s\"\\)\\1\\(\\1\\)"
>   (2
>    (7)))
>  ("\\([RUru]?\\)[Rr]?\\(\\s\"\\)\\2\\(\\2\\)"
>   (1
>    (python-quote-syntax 1))
>   (2
>    (python-quote-syntax 2))
>   (3
>    (python-quote-syntax 3)))))
>
> (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:
>   ;;  ur"""ar""" 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)))
>               (if (featurep 'xemacs)
>                 '(15)
>             (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 "|"))
>           (if (featurep 'xemacs)
>             '(15)
>             (eval-when-compile (string-to-syntax "|")))
>           )))
>      ;; Otherwise (we're in a non-matching string) the property is
>      ;; nil, which is OK.
>      )))
>
> (setq py-mode-syntax-table
>       (let ((table (make-syntax-table))
>             (tablelookup (if (featurep 'xemacs)
>                                      'get-char-table
>                                    'aref)))
>         ;; Give punctuation syntax to ASCII that normally has symbol
>         ;; syntax or has word syntax and isn't a letter.
>         (if (featurep 'xemacs)
>             (setq table (standard-syntax-table))
>           (let ((symbol (if (featurep 'xemacs) '(3)(string-to-syntax "_")))
>                 ;; (symbol (string-to-syntax "_"))
>                 (sst (standard-syntax-table)))
>             (dotimes (i 128)
>               (unless (= i ?_)
>                 (if (equal symbol (funcall tablelookup 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 [hidden email] changed section end
>
424a526
>
508d609
< (put 'python-mode 'font-lock-defaults '(python-font-lock-keywords))
730,771c831,871
< (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 is word class instead of
<   ;; symbol class.  GNU conventions say it should be symbol class, but
<   ;; there's a natural conflict between what major mode authors want
<   ;; and what users expect from `forward-word' and `backward-word'.
<   ;; Guido and I have hashed this out and have decided to keep
<   ;; underscore in word class.  If you're tempted to change it, try
<   ;; binding M-f and M-b to py-forward-into-nomenclature and
<   ;; py-backward-into-nomenclature instead.  This doesn't help in all
<   ;; situations where you'd want the different behavior
<   ;; (e.g. backward-kill-word).
<   (modify-syntax-entry ?\_ "w"  py-mode-syntax-table)
<   ;; Both single quote and double quote are string delimiters
<   (modify-syntax-entry ?\' "\"" py-mode-syntax-table)
<   (modify-syntax-entry ?\" "\"" py-mode-syntax-table)
<   ;; backquote is open and close paren
<   (modify-syntax-entry ?\` "$"  py-mode-syntax-table)
<   ;; comment delimiters
<   (modify-syntax-entry ?\# "<"  py-mode-syntax-table)
<   (modify-syntax-entry ?\n ">"  py-mode-syntax-table)
<   )
---

> ;; (when (featurep 'xemacs) (defvar py-mode-syntax-table nil))
> ;; (when (featurep 'xemacs)
> ;;   (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 is word class instead of
> ;;     ;; symbol class.  GNU conventions say it should be symbol class, but
> ;;     ;; there's a natural conflict between what major mode authors want
> ;;     ;; and what users expect from `forward-word' and `backward-word'.
> ;;     ;; Guido and I have hashed this out and have decided to keep
> ;;     ;; underscore in word class.  If you're tempted to change it, try
> ;;     ;; binding M-f and M-b to py-forward-into-nomenclature and
> ;;     ;; py-backward-into-nomenclature instead.  This doesn't help in all
> ;;     ;; situations where you'd want the different behavior
> ;;     ;; (e.g. backward-kill-word).
> ;;     (modify-syntax-entry ?\_ "w"  py-mode-syntax-table)
> ;;     ;; Both single quote and double quote are string delimiters
> ;;     (modify-syntax-entry ?\' "\"" py-mode-syntax-table)
> ;;     (modify-syntax-entry ?\" "|" py-mode-syntax-table)
> ;;     ;; backquote is open and close paren
> ;;     (modify-syntax-entry ?\` "$"  py-mode-syntax-table)
> ;;     ;; comment delimiters
> ;;     (modify-syntax-entry ?\# "<"  py-mode-syntax-table)
> ;;     (modify-syntax-entry ?\n ">"  py-mode-syntax-table)))
1180d1279
<   (make-local-variable 'font-lock-defaults)
1194a1294,1300
>   ;; 2009-09-10 [hidden email] changed section start
>   ;; from python.el, version "22.1"
>     (set (make-local-variable 'font-lock-defaults)
>        '(python-font-lock-keywords nil nil nil nil
>   (font-lock-syntactic-keywords
>    . python-font-lock-syntactic-keywords)))
>   ;; 2009-09-10 [hidden email] changed section end
1198d1303
<         font-lock-defaults      '(python-font-lock-keywords)
1245,1246c1350
<           (setq indent-tabs-mode nil))
<       ))
---
>           (setq indent-tabs-mode nil))))
1251d1354
<

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Multi-Line Comments

Barry Warsaw
On Dec 11, 2009, at 1:13 PM, Andreas Roehler wrote:

> Already tried to tackle the issue. Works with GNU Emacs for me, not with XEmacs until now.
> Introduced some stuff from python.el - defconst python-font-lock-syntactic-keywords etc.
>
> Patch attached - not polished yet, but works here some weeks now.

Why not push a branch to Launchpad so we can more easily play with it and diff it against trunk?

:)

-Barry

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Multi-Line Comments

Kent Borg
In reply to this post by Andreas Röhler-2
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, but inside a correct multi-line comment, a new ' is happily
ignored.)

> 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?
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.

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Multi-Line Comments

Andreas Röhler-2
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
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: Problem with Multi-Line Comments

Andreas Röhler-2
In reply to this post by Barry Warsaw
Barry Warsaw wrote:

> On Dec 11, 2009, at 1:13 PM, Andreas Roehler wrote:
>
>> Already tried to tackle the issue. Works with GNU Emacs for me, not with XEmacs until now.
>> Introduced some stuff from python.el - defconst python-font-lock-syntactic-keywords etc.
>>
>> Patch attached - not polished yet, but works here some weeks now.
>
> Why not push a branch to Launchpad so we can more easily play with it and diff it against trunk?
>
> :)
>
> -Barry
>
>

Done
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode