From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: Addition to emacsbug.el Date: Fri, 29 Oct 2004 14:28:42 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <11CD2655-29A6-11D9-94D3-000D93505B76@swipnet.se> References: <417F6C5E.5070801@swipnet.se> <417FF8DD.1000408@swipnet.se> <9B209D7F-28A9-11D9-AAAE-000D93505B76@swipnet.se> <24DBCE88-298E-11D9-8B5E-000D93505B76@swipnet.se> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1099053012 11806 80.91.229.6 (29 Oct 2004 12:30:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 29 Oct 2004 12:30:12 +0000 (UTC) Cc: Stefan , emacs devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 29 14:30:03 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CNVtK-0004ec-00 for ; Fri, 29 Oct 2004 14:30:02 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CNW1B-00030h-9f for ged-emacs-devel@m.gmane.org; Fri, 29 Oct 2004 08:38:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CNW11-00030I-G8 for emacs-devel@gnu.org; Fri, 29 Oct 2004 08:37:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CNW10-0002zq-BM for emacs-devel@gnu.org; Fri, 29 Oct 2004 08:37:58 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CNW10-0002zN-9N for emacs-devel@gnu.org; Fri, 29 Oct 2004 08:37:58 -0400 Original-Received: from [195.54.107.73] (helo=mxfep02.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CNVsz-0000wn-Mr for emacs-devel@gnu.org; Fri, 29 Oct 2004 08:29:42 -0400 Original-Received: from coolsville.localdomain ([83.226.180.220] [83.226.180.220]) by mxfep02.bredband.com with ESMTP id <20041029122940.UTWU44.mxfep02.bredband.com@coolsville.localdomain>; Fri, 29 Oct 2004 14:29:40 +0200 In-Reply-To: <24DBCE88-298E-11D9-8B5E-000D93505B76@swipnet.se> Original-To: "Jan D." X-Mailer: Apple Mail (2.619) 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:29142 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29142 >>> If the shown portion of the buffer is small compared to the total >>> size of >>> the buffer, I think the virtual page behaviour is OK. After all, >>> can you >>> see the difference between a thumb who has a height that is 1/30 of >>> the >>> window height, or 1/31? >> >> Agreed: the exact size of the thumb doesn't matter that much. >> >> But I can usually still see whether the thumb is "at the bottom" or >> whether >> there's still one or 2 pixels left, so as long as 1 pixels represents >> about >> 20 lines the difference is "relevant" (i.e. 20 lines =~ 500 chars => >> a buffer of about 500B * 1000 pixels = 500KB for my typical frames). >> >> By "relevant" I don't mean important, but just that it's not 100% >> negligeable. I could probably happily live with the "virtual extra >> page" >> for buffers as small as 50KB. > > I haven't really tested to see where the threshold is for me, but I > think > that sounds reasonable. > >> >>> Otherwise we should do something else, be it your solution or the >>> thumb >>> shrinking one. >>> Actually, after thinking a bit, how about this approach: If the buffer is large enough (for some definition of enough), use the virtual page scrolling (as GTK uses today). If the scroll thumb is not at the bottom (i.e. no overscrolling), scroll as normal (i.e. no shrinking thumb to 0). If the scroll thumb is at the bottom, shrink the thumb to 0. That way it is easier for a user to see that you can actually overscroll, it is not apparent otherwise. Jan D.