GNU bug report logs - #5734
23.1.94; (forward-sexp N) at the very end of large latex-mode buffer takes time proportional to N

Previous Next

Full log

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

From: João Távora <joaotavora <at> gmail.com>
To: 5734 <at> debbugs.gnu.org
Subject: Fwd: 23.1.94;
	(forward-sexp N) at the very end of large latex-mode buffer takes
	time proportional to N
Date: Thu, 25 Mar 2010 20:54:06 +0100

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

Forgot to cc the bug db.

Begin forwarded message:

> From: João Távora <joaotavora <at> gmail.com>
> Date: March 25, 2010 8:52:47 PM GMT+01:00
> To: Chong Yidong <cyd <at> stupidchicken.com>
> Subject: Re: 23.1.94; (forward-sexp N) at the very end of large latex-mode buffer takes time proportional to N
> 
> What about this? This was the workaround I used in autopair.el. The
> idea behind is that if one `latex-forward-sexp-1' went nowhere, the
> next one probably isn't going to. I may be wrong :-)
> 
> === modified file 'lisp/textmodes/tex-mode.el'
> --- lisp/textmodes/tex-mode.el	2010-02-16 02:42:03 +0000
> +++ lisp/textmodes/tex-mode.el	2010-03-25 19:42:59 +0000
> @@ -1651,9 +1651,12 @@
>   "Like `forward-sexp' but aware of multi-char elements and escaped parens."
>   (interactive "P")
>   (unless arg (setq arg 1))
> -  (let ((pos (point)))
> +  (let ((pos (point))
> +        (prev-pos 0))
>     (condition-case err
> -	(while (/= arg 0)
> +	(while (and (not (eq prev-pos (point)))
> +                    (/= arg 0))
> +          (setq prev-pos (point))
> 	  (setq arg
> 		(if (> arg 0)
> 		    (progn (latex-forward-sexp-1) (1- arg))
> 
> PS: I hadn't realised that `tex-mode' defines a `forward-sexp-function'
> hence my ignorant comment about the problem being in syntax.c's scan_list.
> 
> Bye,
> João
> 
> On Mar 25, 2010, at 8:17 PM, Chong Yidong wrote:
> 
> start with `emacs -Q'
> M-x eval-expression RET (insert (make-string 100000 ?a)) RET
> M-x eval-expression RET (latex-mode)                     RET
> M-x eval-expression RET (forward-sexp 200)               RET
> M-x eval-expression RET (forward-sexp 500)               RET
> M-x eval-expression RET (forward-sexp (point-max))       RET
> 
> In some versions of emacs this does not happen, notably my earlier
> Carbon Emacs "GNU Emacs 22.3.1 (i386-apple-darwin9.7.0, Carbon Version
> 1.6.0) of 2009-07-26 on gs674-seijiz.local" after loading some lisp
> libraries (don't know which), like the ones I have bellow (autopair,
> yasnippet).
> 
> I can reproduce this slowness even on Emacs 22.3.  It arises because
> tex-mode wants to be able to signal an error if point is in a containing
> expression that ends prematurely, so it does a bit of backtracking.
> (This is the `skip-syntax-backward' call in latex-forward-sexp-1).
> 
> I'm not sure what the best way to fix this is, though.
> On Mar 25, 2010, at 8:17 PM, Chong Yidong wrote:
> 
>>> start with `emacs -Q'
>>> M-x eval-expression RET (insert (make-string 100000 ?a)) RET
>>> M-x eval-expression RET (latex-mode)                     RET
>>> M-x eval-expression RET (forward-sexp 200)               RET
>>> M-x eval-expression RET (forward-sexp 500)               RET
>>> M-x eval-expression RET (forward-sexp (point-max))       RET
>> 
>>> In some versions of emacs this does not happen, notably my earlier
>>> Carbon Emacs "GNU Emacs 22.3.1 (i386-apple-darwin9.7.0, Carbon Version
>>> 1.6.0) of 2009-07-26 on gs674-seijiz.local" after loading some lisp
>>> libraries (don't know which), like the ones I have bellow (autopair,
>>> yasnippet).
>> 
>> I can reproduce this slowness even on Emacs 22.3.  It arises because
>> tex-mode wants to be able to signal an error if point is in a containing
>> expression that ends prematurely, so it does a bit of backtracking.
>> (This is the `skip-syntax-backward' call in latex-forward-sexp-1).
>> 
>> I'm not sure what the best way to fix this is, though.
> 

[Message part 2 (text/html, inline)]

Previous Next

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