emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Infinite loop in C-x 4 a from C buffers


From: Chong Yidong
Subject: Re: Infinite loop in C-x 4 a from C buffers
Date: Sat, 13 Oct 2007 18:56:10 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

> Try the following:
>
>   emacs -Q src/lisp.h
>   C-s Fplist_put RET
>   C-x 4 a
>
> you should see Emacs get stuck in an infinite loop (not a bad, one: C-g
> stops it just fine).

As Michaël Cadilhac pointed out, this is not an infloop.  On my
computer, the command completes after six or seven seconds.

The fundamental problem is that when add-log-current-defun tries to
find out the current defun, it calls c-beginning-of-defun, which is
very, very slow.  In fact, it's so slow that it might be faster to
perform the same task by scanning forward from the beginning of the
buffer, using c-end-of-defun.

For instance, in src/lisp.h,

  (let ((foo t))
    (goto-char (point-min))
    (while foo
      (setq foo (c-end-of-defun))))

takes about a second to scan to the end of the buffer.  But if you
start from the end of the buffer, a single call to
(c-beginning-of-defun) takes about eight seconds to complete!

I wonder if it would be worthwhile to optimize c-beginning-of-defun
using this observation.  Alan, what do you think?

> PS: BTW, am I the only one who experiences odd slowdowns when editing
> src/lisp.h, apparently due to font-lock occasionally taking a lot of time
> (like a second or two) to do its job.  Not easy to reproduce, sadly.

This is probably due to similar code called in font-lock.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]