unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Infinite loop in C-x 4 a from C buffers
@ 2007-10-10 16:32 Stefan Monnier
  2007-10-10 17:09 ` Michaël Cadilhac
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Stefan Monnier @ 2007-10-10 16:32 UTC (permalink / raw)
  To: emacs-devel

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


        Stefan


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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Infinite loop in C-x 4 a from C buffers
  2007-10-10 16:32 Infinite loop in C-x 4 a from C buffers Stefan Monnier
@ 2007-10-10 17:09 ` Michaël Cadilhac
  2007-10-11  5:20 ` Richard Stallman
  2007-10-13 22:56 ` Chong Yidong
  2 siblings, 0 replies; 4+ messages in thread
From: Michaël Cadilhac @ 2007-10-10 17:09 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel


[-- Attachment #1.1: Type: text/plain, Size: 696 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> 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).

Well, FWIW, it seems that it's just a painly slowness, but not an
infinite loop.  I have to wait something like 8 seconds.

-- 
 |   Michaël `Micha' Cadilhac       |  How come that I am arguing            |
 |   http://michael.cadilhac.name   |      against my idea and               |
 |   JID/MSN:                       |   you are arguing for it?              |
 `----  michael.cadilhac@gmail.com  |          -- David Kastrup         -  --'

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Infinite loop in C-x 4 a from C buffers
  2007-10-10 16:32 Infinite loop in C-x 4 a from C buffers Stefan Monnier
  2007-10-10 17:09 ` Michaël Cadilhac
@ 2007-10-11  5:20 ` Richard Stallman
  2007-10-13 22:56 ` Chong Yidong
  2 siblings, 0 replies; 4+ messages in thread
From: Richard Stallman @ 2007-10-11  5:20 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

    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.

I wonder if this has to do with searching a long way back
to find the place to start scanning from.  

I suspect that is also the cause of the slowness of C-x 4 a.
Is it?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Infinite loop in C-x 4 a from C buffers
  2007-10-10 16:32 Infinite loop in C-x 4 a from C buffers Stefan Monnier
  2007-10-10 17:09 ` Michaël Cadilhac
  2007-10-11  5:20 ` Richard Stallman
@ 2007-10-13 22:56 ` Chong Yidong
  2 siblings, 0 replies; 4+ messages in thread
From: Chong Yidong @ 2007-10-13 22:56 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Alan Mackenzie, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> 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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-10-13 22:56 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-10-10 16:32 Infinite loop in C-x 4 a from C buffers Stefan Monnier
2007-10-10 17:09 ` Michaël Cadilhac
2007-10-11  5:20 ` Richard Stallman
2007-10-13 22:56 ` Chong Yidong

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).