emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scrollbar thumbs


From: Stephen J. Turnbull
Subject: Re: Scrollbar thumbs
Date: Fri, 06 Nov 2009 12:10:58 +0900

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]