From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Buffer Boundary Problem Date: 02 Feb 2004 10:46:23 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <401C36D3.4050609@ig.com.br> <20040201001317.GD16423@fencepost> <401C508C.1040902@ig.com.br> <87k7376mq1.fsf@dugong.chemistry.nottingham.ac.uk> <401CF17E.8040908@swipnet.se> <401CF70C.1030309@swipnet.se> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1075712353 18848 80.91.224.253 (2 Feb 2004 08:59:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 2 Feb 2004 08:59:13 +0000 (UTC) Cc: Matt Hodges , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Feb 02 09:58:53 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AnZuv-0004cQ-00 for ; Mon, 02 Feb 2004 09:58:53 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AnZuv-0001Vu-00 for ; Mon, 02 Feb 2004 09:58:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AnZq9-000794-WB for emacs-devel@quimby.gnus.org; Mon, 02 Feb 2004 03:53:58 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AnZpj-0006vu-82 for emacs-devel@gnu.org; Mon, 02 Feb 2004 03:53:31 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AnZml-0005pm-Mk for emacs-devel@gnu.org; Mon, 02 Feb 2004 03:50:59 -0500 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.24) id 1AnZiu-0004pL-Lt for emacs-devel@gnu.org; Mon, 02 Feb 2004 03:46:28 -0500 Original-Received: (qmail 54351 invoked from network); 2 Feb 2004 08:46:26 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 2 Feb 2004 08:46:26 -0000 Original-To: "Jan D." In-Reply-To: <401CF70C.1030309@swipnet.se> Original-Lines: 25 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:19642 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19642 "Jan D." writes: > Oh, now I get it. Its the arrows in the fringes. I didn't even see > them first. Anyway, it is unrelated to scrollbars, I see the same > effect for Motif, Lesstif, Lucid and Xaw(3d) scroll bars. However, I > can not find any code that clear the fringes, just draws, so it is not > surprising that you get an arrow in the middle sometimes. It is the > arrow that was at the bottom that has been moved up, and since fringes > are not cleared before redrawn, it stays. It is true that fringes are not cleared before they are redrawn, as the redisplay code tries to minimize the amount of redrawing -- so it actually tries to remember which bitmaps are currently in the fringe and only delete them if they are no longer needed at a certain position. The problem with the extra arrows is that some scrolling operations work directly on the existing glyph matrix, so extra care is needed to clean-up the fringe bitmaps that are scrolled with the text. Since there are several such optimizations in the redisplay code, the fringe redisplay code also need to be aware of those optimizations. Currently there are some corner cases which it fails to handle. ++kfs