Re: Gtk scrollbar: thumb too short

[Owen Taylor <otaylor@redhat.com>]

On Thu, 2003-03-27 at 11:30, Stefan Monnier wrote:
> >  * I've always found the emacs behavior with respect to the end of the
> >    buffer quite confusing personally... I think it would be far
> >    less confusing if the region that was scrolled was actually
> >    confined to the lines of the buffer (or maybe lines in buffer + 1)
> 
> Less confusing but pretty damn hard.  I'll implement it as soon as you
> provide me with a moderately efficient function F that maps from
> top-of-the-scrollbar-position (in % of the scrollbar size) to
> window-start-position (in characters) such that F(100%) ensures
> that (point-max) is visible.
> 
> Of course, if the last char of the buffer is a large image, the behavior
> will be quite different from the case where the last 100KB of the buffer
> are invisible.  Which is where the "moderately efficient" constraint
> becomes relevant.

Well, if _displaying_ the last page of text can be done with 
reasonable efficiency, you should also be to compute this quantity
with reasonable efficiency.... you just start from the end, and
scan backwards for newlines and compute the height of each line
until you get enough pixels. Then you have to recompute 
(queue a recomputation) any time there is a change in the 
buffer that affects those lines.

But yes, that's probably reasonably complex to implement and there 
is no real bound on the amount of text you might have to look at and lay
out to compute this quantity.

Frankly, I tend to turn off or just not look at the scrollbar because
these same issues make it behave in a confusing manner in general.
(Presumably, if you have a large chunks of hidden text anywhere in
your document, the scrollbar will go whacky.)

While writing text editors with pixel based scrollbars is a subject
with lots of prior art, I'm under no illusions that Emacs could be
switched over without huge changes both to its code and to its
efficiency.

> >    (Emacs-21.2 with Xaw3d seems to be just buggy ... if the user drags
> >    the thumb of the scrollbar past the end of the buffer it shrinks
> >    to a smaller size and doesn't come back.)
> 
> Could you describe the bug more precisely.  I don't expect the behavior
> to be perfect, but "doesn't come back" sounds serious (unless you're just
> talking about the size of the thumb: it only decreases while you drag
> to avoid nasty "meta-stable" flicker, so the size will only be reset to
> the proper value when the drag is over).

I am talking about the size of the thumb. Not only does it not come
back when dragging (which, while it may be intentional, looks 
very much like a bug), it also doesn't come back after you release,
until you move the scrollbar again.

Regards,
                                           Owen