GNU bug report logs - #13182
[PATCH] long delays in python-mode buffer parsing

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13182 in the body.
You can then email your comments to 13182 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] long delays in python-mode buffer parsing
Date: Fri, 14 Dec 2012 03:40:28 -0800

[Message part 1 (text/plain, inline)]

Some python-mode operations slow down noticeably when the region being edited
contains an unclosed bracket or string: these constructs lead to python-mode
scanning the entire remainder of the buffer, and this scan appears to take time
O(nr_lines^2). When which-func mode is enabled, this slowness renders Emacs
unusable, since we'll call python-info-current-defun frequently in order to
update the modeline, and this function will take several seconds to complete.

The following patch appears to remedy the problem without breaking anythig.

=== modified file 'lisp/progmodes/python.el'
--- lisp/progmodes/python.el	2012-11-27 03:10:32 +0000
+++ lisp/progmodes/python.el	2012-12-14 11:28:58 +0000
@@ -1184,13 +1184,21 @@
 (defun python-nav-end-of-statement ()
   "Move to end of current statement."
   (interactive "^")
-  (while (and (goto-char (line-end-position))
-              (not (eobp))
-              (when (or
-                     (python-info-line-ends-backslash-p)
-                     (python-syntax-context 'string)
-                     (python-syntax-context 'paren))
-                (forward-line 1))))
+
+  (let (string-start bs-pos)
+    (while (and (goto-char (line-end-position))
+                (not (eobp))
+                (cond ((setq string-start (python-syntax-context 'string))
+                       (goto-char string-start)
+                       (forward-sexp))
+                      ((python-syntax-context 'paren)
+                       ;; The statement won't end before we've escaped
+                       ;; at least one level of parenthesis.
+                       (condition-case err
+                           (goto-char (scan-lists (point) 1 -1))
+                         (scan-error (goto-char (nth 3 err)))))
+                      ((setq bs-pos (python-info-line-ends-backslash-p))
+                       (goto-char bs-pos))))))
   (point-marker))

 (defun python-nav-backward-statement (&optional arg)

[signature.asc (application/pgp-signature, attachment)]

Message #8 received at 13182 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: 13182 <at> debbugs.gnu.org
Subject: Re: bug#13182: [PATCH] long delays in python-mode buffer parsing
Date: Fri, 14 Dec 2012 22:44:19 -0800

[Message part 1 (text/plain, inline)]

On 12/14/2012 3:40 AM, Daniel Colascione wrote:
> Some python-mode operations slow down noticeably when the region being edited
> contains an unclosed bracket or string: these constructs lead to python-mode
> scanning the entire remainder of the buffer, and this scan appears to take time
> O(nr_lines^2). When which-func mode is enabled, this slowness renders Emacs
> unusable, since we'll call python-info-current-defun frequently in order to
> update the modeline, and this function will take several seconds to complete.
> 
> The following patch appears to remedy the problem without breaking anythig.

Here's a bugfixed patch. Review would be appreciated.

=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2012-12-10 18:33:59 +0000
+++ lisp/ChangeLog	2012-12-15 06:38:59 +0000
@@ -1,3 +1,12 @@
+2012-12-15  Daniel Colascione  <dancol <at> dancol.org>
+
+	* progmodes/python.el (python-nav-end-of-statement): Don't loop forever.
+
+2012-12-14  Daniel Colascione  <dancol <at> dancol.org>
+
+	* progmodes/python.el (python-nav-end-of-statement): Rewrite in
+	order to improve efficiency.
+
 2012-12-10  Jambunathan K  <kjambunathan <at> gmail.com>

 	* hi-lock.el: Refine the choice of default face.

=== modified file 'lisp/progmodes/python.el'
--- lisp/progmodes/python.el	2012-11-27 03:10:32 +0000
+++ lisp/progmodes/python.el	2012-12-15 06:28:38 +0000
@@ -1184,13 +1184,23 @@
 (defun python-nav-end-of-statement ()
   "Move to end of current statement."
   (interactive "^")
-  (while (and (goto-char (line-end-position))
-              (not (eobp))
-              (when (or
-                     (python-info-line-ends-backslash-p)
-                     (python-syntax-context 'string)
-                     (python-syntax-context 'paren))
-                (forward-line 1))))
+
+  (let (string-start bs-pos)
+    (while (and (goto-char (line-end-position))
+                (not (eobp))
+                (cond ((setq string-start (python-syntax-context 'string))
+                       (goto-char string-start)
+                       (let (forward-sexp-function)
+                         (forward-sexp)))
+                      ((python-syntax-context 'paren)
+                       ;; The statement won't end before we've escaped
+                       ;; at least one level of parenthesis.
+                       (condition-case err
+                           (goto-char (scan-lists (point) 1 -1))
+                         (scan-error (goto-char (nth 3 err)))))
+                      ((setq bs-pos (python-info-line-ends-backslash-p))
+                       (goto-char bs-pos)
+                       (forward-line 1))))))
   (point-marker))

 (defun python-nav-backward-statement (&optional arg)

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at 13182 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 13182 <at> debbugs.gnu.org
Subject: Re: bug#13182: [PATCH] long delays in python-mode buffer parsing
Date: Sat, 15 Dec 2012 09:50:48 -0500

> Here's a bugfixed patch. Review would be appreciated.

It looks fine in general.  I prefer using forward-sexp over scan-lists,
but that's just a personal preference.  Also, a single changelog entry
will do, if you commit it as a single commit.


        Stefan

Message #14 received at 13182 <at> debbugs.gnu.org (full text, mbox):

From: Fabián Ezequiel Gallina <fabian <at> anue.biz>
To: 13182 <at> debbugs.gnu.org
Subject: [PATCH] long delays in python-mode buffer parsing
Date: Fri, 28 Dec 2012 12:29:18 -0300

The patch looks good and given this is a speed regression this should be 
committed to the emacs-24 branch, please do it and then we can close 
this bug.


Thanks,
Fabián.

Message #17 received at 13182 <at> debbugs.gnu.org (full text, mbox):

From: Fabián Ezequiel Gallina <fabian <at> anue.biz>
To: 13182 <at> debbugs.gnu.org
Subject: [PATCH] long delays in python-mode buffer parsing
Date: Mon, 31 Dec 2012 18:02:06 -0300

I just installed a modified version of your patch in revno 111108.

This modified version would jump correctly to the end of defun in the 
following context:

    doing_something("""
    This is preformatted text and should not be indented to the level 
of the parentheses.
    """
    )

Message #22 received at 13182 <at> debbugs.gnu.org (full text, mbox):

From: Fabián Ezequiel Gallina <fabian <at> anue.biz>
To: 13182 <at> debbugs.gnu.org
Subject: [PATCH] long delays in python-mode buffer parsing
Date: Mon, 31 Dec 2012 18:05:52 -0300

s/defun/statement/

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.