From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Scrollbar thumbs Date: Fri, 06 Nov 2009 12:10:58 +0900 Message-ID: <87skcs2vr1.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1257476582 17552 80.91.229.12 (6 Nov 2009 03:03:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Nov 2009 03:03:02 +0000 (UTC) Cc: David Kastrup , emacs-devel@gnu.org To: Jason Rumney Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 06 04:02:54 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 1N6F6D-0003bS-Cl for ged-emacs-devel@m.gmane.org; Fri, 06 Nov 2009 04:02:53 +0100 Original-Received: from localhost ([127.0.0.1]:38272 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N6F6C-0004KK-8P for ged-emacs-devel@m.gmane.org; Thu, 05 Nov 2009 22:02:52 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N6F64-0004Js-3R for emacs-devel@gnu.org; Thu, 05 Nov 2009 22:02:44 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N6F5z-0004Im-G5 for emacs-devel@gnu.org; Thu, 05 Nov 2009 22:02:43 -0500 Original-Received: from [199.232.76.173] (port=60985 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N6F5z-0004Ij-BK for emacs-devel@gnu.org; Thu, 05 Nov 2009 22:02:39 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:45867) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N6F5u-00080q-Vs; Thu, 05 Nov 2009 22:02:35 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id 140BD820E; Fri, 6 Nov 2009 12:02:30 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 155331A266C; Fri, 6 Nov 2009 12:10:58 +0900 (JST) In-Reply-To: <4AF36607.50508@gnu.org> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" d20e0a45a4b2 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:116671 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. AFAICT XEmacs counts *characters*, not lines. This means that a page with lots of empty lines gets a smaller thumb than one with almost all lines full-width. (It's observable that the thumbs change size.) This would also give consistent results between long-lines support (ie, proper wrapping of newline-delimited paragraphs) and conventional newline-delimited lines. Of course it's not possible to jump to a particular page in this algorithm, but modern apps don't seem to do this with scrollbars anymore anyway. They provide a separate tray of thumbnails (which gets its own scrollbar). I don't recall seeing a question about this on XEmacs channels, nor complaints that scrollbars function differently on different platforms. > 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. That is not acceptable on a 128MB log file, though. Typically what you want to look at *first* is the end of the file. > 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. This is a big deal? All you need is the heights of the pages. You recalculate spillage into or out of the current page as you redisplay, the previous pages don't change at all, and you approximate the later pages as not having changed length.