From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: delete-overlay causes recentering Date: Mon, 23 Apr 2007 21:35:53 -0400 Message-ID: <87zm4yr1ty.fsf@stupidchicken.com> References: <25771086.79401173867519911.JavaMail.www@wwinf4104> <87fy72v2bs.fsf@stupidchicken.com> <87zm5av218.fsf@stupidchicken.com> <873b31e9tq.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1177378568 16410 80.91.229.12 (24 Apr 2007 01:36:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 24 Apr 2007 01:36:08 +0000 (UTC) Cc: emacs-devel@gnu.org, Johan =?utf-8?Q?Bockg=C3=A5rd?= To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 24 03:36:05 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Hg9wq-0000v3-H2 for ged-emacs-devel@m.gmane.org; Tue, 24 Apr 2007 03:36:04 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HgA2I-0001UE-G6 for ged-emacs-devel@m.gmane.org; Mon, 23 Apr 2007 21:41:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HgA2F-0001U7-Jc for emacs-devel@gnu.org; Mon, 23 Apr 2007 21:41:39 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HgA2E-0001Tf-VF for emacs-devel@gnu.org; Mon, 23 Apr 2007 21:41:38 -0400 Original-Received: from south-station-annex.mit.edu ([18.72.1.2]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Hg9wm-0000qn-3i; Mon, 23 Apr 2007 21:36:00 -0400 Original-Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id l3O1Zv9o005281; Mon, 23 Apr 2007 21:35:57 -0400 (EDT) Original-Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104]) by grand-central-station.mit.edu (8.13.6/8.9.2) with ESMTP id l3O1Zs74024317; Mon, 23 Apr 2007 21:35:54 -0400 (EDT) Original-Received: from localhost (SYDNEYPACIFIC-SIX-THIRTY-FOUR.MIT.EDU [18.95.7.123]) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id l3O1ZrrA012161; Mon, 23 Apr 2007 21:35:54 -0400 (EDT) Original-Received: from cyd by localhost with local (Exim 3.36 #1 (Debian)) id 1Hg9wg-0005NL-00; Mon, 23 Apr 2007 21:35:54 -0400 In-Reply-To: (Richard Stallman's message of "Mon\, 23 Apr 2007 19\:07\:48 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.98 (gnu/linux) X-Scanned-By: MIMEDefang 2.42 X-Spam-Score: -2.599 X-detected-kernel: Solaris 9.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:69892 Archived-At: Richard Stallman writes: > When a window starts is in a continued line, it is recentered whenever > the window is unselected--by activating the minibuffer, switching to > another window, or switching to another frame. > > That is the spurious scrolling bug I have mentioned. Thank you > for connecting it with specific code. Now it should be possible > to track it down. > > Yidong wrote: > > I don't know an easy way to fix this. > > Can you describe the series of events that cause the > spurious recentering? KFS described the problem in the original change that led to this: When the filling command has reformatted the buffer text, the redisplay code still starts window display at the old window start -- which still is in the middle of a line, but not at the same relative position in the line as before ... so it gets confused. This is just one way in which a buffer change can mess things up when window start is not at the start of a line, so I think it is generally a bit difficult to find a method which will always select the intuitively best window start after such a change. As a result, there will be times when the redisplay engine must recenter, simply to avoid screen corruption. On the other hand, I just realized that the "recentering due to minibuffer-activation" problem is a simple oversight on my part, when I was fixing the recentering to make it less aggressive. I've checked in a small fix.