From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Scrollbar thumbs Date: Fri, 06 Nov 2009 09:42:53 +0100 Organization: Organization?!? Message-ID: <87my30jb76.fsf@lola.goethe.zz> References: <03A2EC54153A4BB1AAE5AF2D2E2B7264@editkapc> <87aaz3jgkp.fsf@catnip.gol.com> <4AF1D60C.6080005@swipnet.se> <87skctklaz.fsf@lola.goethe.zz> <4AF36607.50508@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1257497024 30689 80.91.229.12 (6 Nov 2009 08:43:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Nov 2009 08:43:44 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 06 09:43:37 2009 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 1N6KPw-0005NJ-Li for ged-emacs-devel@m.gmane.org; Fri, 06 Nov 2009 09:43:36 +0100 Original-Received: from localhost ([127.0.0.1]:48750 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N6KPw-0003Ua-5t for ged-emacs-devel@m.gmane.org; Fri, 06 Nov 2009 03:43:36 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N6KPp-0003UJ-Uk for emacs-devel@gnu.org; Fri, 06 Nov 2009 03:43:29 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N6KPk-0003Sa-VJ for emacs-devel@gnu.org; Fri, 06 Nov 2009 03:43:29 -0500 Original-Received: from [199.232.76.173] (port=57643 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N6KPk-0003SV-Nw for emacs-devel@gnu.org; Fri, 06 Nov 2009 03:43:24 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:34130) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N6KPk-0004ZL-8B for emacs-devel@gnu.org; Fri, 06 Nov 2009 03:43:24 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1N6KPc-0005FJ-3h for emacs-devel@gnu.org; Fri, 06 Nov 2009 09:43:16 +0100 Original-Received: from p5b2c22df.dip.t-dialin.net ([91.44.34.223]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Nov 2009 09:43:16 +0100 Original-Received: from dak by p5b2c22df.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Nov 2009 09:43:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 34 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p5b2c22df.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:Zg4CWvkKnd6VjK7lS0npCN2gWU0= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:116676 Archived-At: Jason Rumney writes: > David Kastrup wrote: > >> The "design flaw" is that Emacs has a variable line height. An editor >> is primarily supposed to deal with lines of text, not with continuous >> graphical panes. And previous to Emacs 21, Emacs only dealt with lines >> of text of constant height. Previous to Emacs 19, the lines >> corresponded 1:1 to the screen lines. >> > Even Emacs 19 had line wrapping, so counting CR characters as the file > is read (as some simple text editors do) has never been the solution > to this problem. The only solution seems to be to render the entire > buffer offscreen in background, adjusting the scrollbar as we get more > detailed information about the real contents of the buffer. This is > what word processors, web browsers and other complex applications do - > you see the first page quite quickly, then you see the scroll bar > growing as it renders the buffer in background. Most applications do > not even make an initial guess, so you cannot scroll to the bottom of > the buffer until the background rendering is finished. The application > then needs to use extra memory to cache the metrics it has calculated > to avoid having to rerender the entire document on every change. Actually, the inability to get such an application in combination with the castrated scroll bar semantics scroll half a screen down is quite annoying. The only way you can scroll a half-screen (without Athena-style scrollbar behavior) is by dragging, and particularly dragging in large documents while the scrollbar self-updates is utterly haphazard. Usually you completely use your place. I don't see that this is a useful model of behavior for an editor. -- David Kastrup