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: Sun, 15 Apr 2007 15:06:41 -0400 Message-ID: <873b31e9tq.fsf@stupidchicken.com> References: <25771086.79401173867519911.JavaMail.www@wwinf4104> <87fy72v2bs.fsf@stupidchicken.com> <87zm5av218.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 1176664133 31700 80.91.229.12 (15 Apr 2007 19:08:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 15 Apr 2007 19:08:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Kim F.Storm" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 15 21:08:44 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 1HdA5a-0002Vb-LQ for ged-emacs-devel@m.gmane.org; Sun, 15 Apr 2007 21:08:42 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HdAA6-0000aY-W2 for ged-emacs-devel@m.gmane.org; Sun, 15 Apr 2007 15:13:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HdAA3-0000aJ-4l for emacs-devel@gnu.org; Sun, 15 Apr 2007 15:13:19 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HdAA1-0000aB-Rw for emacs-devel@gnu.org; Sun, 15 Apr 2007 15:13:17 -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 1HdA5U-0001k6-Lt for emacs-devel@gnu.org; Sun, 15 Apr 2007 15:08:36 -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 l3FJ8ScI008329; Sun, 15 Apr 2007 15:08:33 -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 l3FJ8ERH021764; Sun, 15 Apr 2007 15:08:20 -0400 (EDT) Original-Received: from localhost (SYDNEYPACIFIC-SEVEN-FIFTY-SEVEN.MIT.EDU [18.95.7.246]) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id l3FJ8DN6012549; Sun, 15 Apr 2007 15:08:14 -0400 (EDT) Original-Received: from cyd by localhost with local (Exim 3.36 #1 (Debian)) id 1HdA45-0004Uz-00; Sun, 15 Apr 2007 15:07:09 -0400 In-Reply-To: <87zm5av218.fsf@stupidchicken.com> (Chong Yidong's message of "Sat\, 14 Apr 2007 21\:50\:43 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.97 (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:69464 Archived-At: Chong Yidong writes: >> The behavior arose from the following change: >> >> 2006-04-20 Kim F. Storm >> >> * xdisp.c (redisplay_window): Fix last change. >> >> * xdisp.c (redisplay_window): If current window start is not at the >> beginning of a line, select a new window start if buffer is modified >> and window start is in the modified region, but the first change is >> before window start. The problem is in the part of the code at xdisp.c:13145: /* Make sure beg_unchanged and end_unchanged are up to date. Do it only if buffer has really changed. This may or may not have been done by try_window_id (see which) already. */ if (MODIFF > SAVE_MODIFF /* This seems to happen sometimes after saving a buffer. */ || BEG_UNCHANGED + END_UNCHANGED > Z_BYTE) { if (GPT - BEG < BEG_UNCHANGED) BEG_UNCHANGED = GPT - BEG; if (Z - GPT < END_UNCHANGED) END_UNCHANGED = Z - GPT; } This code seems to be copied from try_window_id. I am not sure what the original justification for this is, but it is a little too strict when it comes to overlay changes. That's because modify_overlay (buffer.c:3703), which is used to mark overlay changes, calls BUF_COMPUTE_UNCHANGED, which alters BUF_BEG_UNCHANGED and BUF_END_UNCHANGED directly without moving the gap. However, the result is that the "make sure beg_unchanged and end_unchanged are up to date" check, which compares these to the actual gap positions, thinks more of the buffer has been modified than it actually has. It then proceeds to recenter the display. If we use the original values of BEG_UNCHANGED and END_UNCHANGED, before it is "updated" by the above code, the spurious recentering does not take place. The original (2006) test case also seems to behave OK -- in that case, we recenter correctly. However, I can't be certain this is correct because I don't know the original justification for the above check. WDYT?