GNU bug report logs - #5749
append-to-buffer and point

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 5749 in the body.
You can then email your comments to 5749 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: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; Gomoku startup latency
Date: Fri, 19 Mar 2010 23:50:35 +0100

1. Let ~/.emacs consist of this sexp:
(setq initial-frame-alist '((fullscreen . fullheight)))
2. Start Emacs with the above init file.
3. M-x gomoku
=> There is a noticeable delay loading the game -- on my system 3-4
seconds.  This also occurs when the height frame parameter is assigned a
corresponding integer value.  The latency decreases as the height value
decreases.  (At the default height of 35, the startup time is
practically instantaneous.)

In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.18.6)
 of 2010-03-19 on escher
Windowing system distributor `The X.Org Foundation', version 11.0.10605000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

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

From: Glenn Morris <rgm <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 5749 <at> debbugs.gnu.org
Subject: Re: bug#5749: 24.0.50; Gomoku startup latency
Date: Tue, 23 Mar 2010 21:51:24 -0400

Stephen Berman wrote:

> 1. Let ~/.emacs consist of this sexp:
> (setq initial-frame-alist '((fullscreen . fullheight)))
> 2. Start Emacs with the above init file.
> 3. M-x gomoku
> => There is a noticeable delay loading the game -- on my system 3-4
> seconds.

This is interesting. Emacs 23.1 is almost instantaneous, but 23.1.94
is very slow, and also starts using a huge amount of memory (1GB+ for me).
Loading gomoku.el from 23.1 in 23.1.94 makes no difference.

In 23.1.94, the values of cons-cells-consed and intervals-consed go up
enormously (by ~ 70 million and 10 million) after running `gomoku'.

> In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.18.6)
>  of 2010-03-19 on escher

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, 5749 <at> debbugs.gnu.org
Subject: Re: bug#5749: 24.0.50; Gomoku startup latency
Date: Tue, 23 Mar 2010 23:15:08 -0400

>> 1. Let ~/.emacs consist of this sexp:
>> (setq initial-frame-alist '((fullscreen . fullheight)))
>> 2. Start Emacs with the above init file.
>> 3. M-x gomoku
>> => There is a noticeable delay loading the game -- on my system 3-4
>> seconds.

> This is interesting. Emacs 23.1 is almost instantaneous, but 23.1.94
> is very slow, and also starts using a huge amount of memory (1GB+ for me).
> Loading gomoku.el from 23.1 in 23.1.94 makes no difference.

Indeed.  ELP says the time is all spent in insert-buffer-substring,
called via append-to-buffer (in my case, 13 calls of 0.5s each).


        Stefan

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

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, 5749 <at> debbugs.gnu.org
Subject: Re: bug#5749: 24.0.50; Gomoku startup latency
Date: Wed, 24 Mar 2010 12:27:03 +0900

>>>>> On Tue, 23 Mar 2010 21:51:24 -0400, Glenn Morris <rgm <at> gnu.org> said:

> Stephen Berman wrote:
>> 1. Let ~/.emacs consist of this sexp:
>> (setq initial-frame-alist '((fullscreen . fullheight)))
>> 2. Start Emacs with the above init file.
>> 3. M-x gomoku
>> => There is a noticeable delay loading the game -- on my system 3-4
>> seconds.

> This is interesting. Emacs 23.1 is almost instantaneous, but 23.1.94
> is very slow, and also starts using a huge amount of memory (1GB+ for me).
> Loading gomoku.el from 23.1 in 23.1.94 makes no difference.

This is due to a behavioral change of `append-to-buffer', which used
to preserve the point when the first argument coincides with the
current buffer.  The following patch would work for this case.

Maybe other occurrences of `(append-to-buffer (current-buffer) ...)'
should also be checked if they work as intended.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

=== modified file 'lisp/play/gomoku.el'
*** lisp/play/gomoku.el	2010-01-13 08:35:10 +0000
--- lisp/play/gomoku.el	2010-03-24 03:04:35 +0000
***************
*** 1040,1046 ****
  		    (= i (- m 2))
  		    (progn
  		      (while (>= i 3)
! 			(append-to-buffer (current-buffer) opoint (point))
  			(setq i (- i 2)))
  		      (goto-char (point-max))))
  	       (setq point (point))
--- 1040,1046 ----
  		    (= i (- m 2))
  		    (progn
  		      (while (>= i 3)
! 			(prepend-to-buffer (current-buffer) opoint (point))
  			(setq i (- i 2)))
  		      (goto-char (point-max))))
  	       (setq point (point))

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

From: Glenn Morris <rgm <at> gnu.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 5749 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#5749: 24.0.50; Gomoku startup latency
Date: Wed, 24 Mar 2010 00:03:53 -0400

YAMAMOTO Mitsuharu wrote:

> This is due to a behavioral change of `append-to-buffer', which used
> to preserve the point when the first argument coincides with the
> current buffer.

This change doesn't seem to be documented in NEWS, was it intentional?

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Glenn Morris <rgm <at> gnu.org>, 5749 <at> debbugs.gnu.org
Subject: Re: bug#5749: 24.0.50; Gomoku startup latency
Date: Wed, 24 Mar 2010 10:14:35 +0100

On Wed, 24 Mar 2010 12:27:03 +0900 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp> wrote:

>>>>>> On Tue, 23 Mar 2010 21:51:24 -0400, Glenn Morris <rgm <at> gnu.org> said:
>
>> Stephen Berman wrote:
>>> 1. Let ~/.emacs consist of this sexp:
>>> (setq initial-frame-alist '((fullscreen . fullheight)))
>>> 2. Start Emacs with the above init file.
>>> 3. M-x gomoku
>>> => There is a noticeable delay loading the game -- on my system 3-4
>>> seconds.
>
>> This is interesting. Emacs 23.1 is almost instantaneous, but 23.1.94
>> is very slow, and also starts using a huge amount of memory (1GB+ for me).
>> Loading gomoku.el from 23.1 in 23.1.94 makes no difference.
>
> This is due to a behavioral change of `append-to-buffer', which used
> to preserve the point when the first argument coincides with the
> current buffer.  The following patch would work for this case.

I confirm that this patch eliminates the startup latency for me.

Steve Berman

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 5749 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
	YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#5749: 24.0.50; Gomoku startup latency
Date: Wed, 24 Mar 2010 11:28:43 -0400

Glenn Morris <rgm <at> gnu.org> writes:

> YAMAMOTO Mitsuharu wrote:
>
>> This is due to a behavioral change of `append-to-buffer', which used
>> to preserve the point when the first argument coincides with the
>> current buffer.
>
> This change doesn't seem to be documented in NEWS, was it intentional?

I suspect this was done as part of Stefan's mass conversion of code to
with-current-buffer.

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Glenn Morris <rgm <at> gnu.org>, Stephen Berman <stephen.berman <at> gmx.net>,
	5749 <at> debbugs.gnu.org
Subject: Re: bug#5749: 24.0.50; Gomoku startup latency
Date: Wed, 24 Mar 2010 12:18:59 -0400

YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp> writes:

> This is due to a behavioral change of `append-to-buffer', which used
> to preserve the point when the first argument coincides with the
> current buffer.

I've changed append-to-buffer to conform to the previous behavior.

Could someone check whether gomoku works properly now?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 5749 <at> debbugs.gnu.org,
	YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#5749: 24.0.50; Gomoku startup latency
Date: Wed, 24 Mar 2010 13:27:26 -0400

>>> This is due to a behavioral change of `append-to-buffer', which used
>>> to preserve the point when the first argument coincides with the
>>> current buffer.
>> This change doesn't seem to be documented in NEWS, was it intentional?
> I suspect this was done as part of Stefan's mass conversion of code to
> with-current-buffer.

Indeed.  Note that the new behavior happens to be more correct w.r.t its
docstring:

   It is inserted into that buffer before its point.

so it promises to move point in the specified buffer.  At first
I thought we should fix append-to-buffer to behave as it used to, but
now I'm wondering whether we should fix the uses instead.



        Stefan

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 5749 <at> debbugs.gnu.org, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#5749: 24.0.50; Gomoku startup latency
Date: Wed, 24 Mar 2010 20:05:50 +0100

On Wed, 24 Mar 2010 12:18:59 -0400 Chong Yidong <cyd <at> stupidchicken.com> wrote:

> YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp> writes:
>
>> This is due to a behavioral change of `append-to-buffer', which used
>> to preserve the point when the first argument coincides with the
>> current buffer.
>
> I've changed append-to-buffer to conform to the previous behavior.
>
> Could someone check whether gomoku works properly now?

I applied your change (after reverting Yamamoto-san's change I had
previously applied) and confirm it also eliminates the startup latency.

Steve Berman

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Glenn Morris <rgm <at> gnu.org>, 5749 <at> debbugs.gnu.org,
	YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#5749: 24.0.50; Gomoku startup latency
Date: Wed, 24 Mar 2010 16:19:20 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Indeed.  Note that the new behavior happens to be more correct w.r.t its
> docstring:
>
>    It is inserted into that buffer before its point.
>
> so it promises to move point in the specified buffer.  At first
> I thought we should fix append-to-buffer to behave as it used to, but
> now I'm wondering whether we should fix the uses instead.

I've changed it to behave as it used to in the branch, because who know
how many other packages rely on the same assumption gomoku did.

As for whether to switch to the new behavior in the trunk, if so it
should be documented.

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

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 5749 <at> debbugs.gnu.org,
	Stefan Monnier <monnier <at> iro.umontreal.ca>,
	YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#5749: 24.0.50; Gomoku startup latency
Date: Thu, 25 Mar 2010 08:44:33 +0900

>>>>> On Wed, 24 Mar 2010 16:19:20 -0400, Chong Yidong <cyd <at> stupidchicken.com> said:

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> Indeed.  Note that the new behavior happens to be more correct
>> w.r.t its docstring:
>> 
>>   It is inserted into that buffer before its point.
>> 
>> so it promises to move point in the specified buffer.  At first I
>> thought we should fix append-to-buffer to behave as it used to, but
>> now I'm wondering whether we should fix the uses instead.

That's exactly what I thought, and that's why I posted a patch that
changes (append-to-buffer (current-buffer) ...) to (prepend-to-buffer
(current-buffer) ...), rather than reverting append-to-buffer.

> I've changed it to behave as it used to in the branch, because who
> know how many other packages rely on the same assumption gomoku did.

> As for whether to switch to the new behavior in the trunk, if so it
> should be documented.

If it is changed in the trunk, then it might be good to add some
notices to documents in Emacs 23.2, telling the behavior of
append-to-buffer might change in future with respect to the current
buffer, and suggesting prepend-to-buffer for those cases to make the
behavior consistent.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

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

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 5749 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>,
	Stephen Berman <stephen.berman <at> gmx.net>,
	YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#5749: 24.0.50; Gomoku startup latency
Date: Thu, 25 Mar 2010 13:08:58 +0900

>>>>> On Wed, 24 Mar 2010 12:18:59 -0400, Chong Yidong <cyd <at> stupidchicken.com> said:

> YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp> writes:
>> This is due to a behavioral change of `append-to-buffer', which
>> used to preserve the point when the first argument coincides with
>> the current buffer.

> I've changed append-to-buffer to conform to the previous behavior.

Not actually.  It has changed the behavior for the case that the
destination buffer is *not* the current one (especially, when the
destigation buffer does not have any windows).

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Glenn Morris <rgm <at> gnu.org>, Stephen Berman <stephen.berman <at> gmx.net>,
	5749 <at> debbugs.gnu.org
Subject: Re: bug#5749: 24.0.50; Gomoku startup latency
Date: Thu, 25 Mar 2010 01:54:59 -0400

YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp> writes:

>> I've changed append-to-buffer to conform to the previous behavior.
>
> Not actually.  It has changed the behavior for the case that the
> destination buffer is *not* the current one (especially, when the
> destigation buffer does not have any windows).

Sorry, should be fixed now.  Thanks for checking.

Previous Next

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