Re: Gtk scrollbar: thumb too short

[Richard Stallman]

    Bug or feature?  I do not know whether there is a "correct" answer to
    that question.  It depends on what the user is trying to do and on the
    user's taste and expectations.

I think we should consider it a feature.  Consider outline mode, for
instance.  I think it is correct that the scroll bar indicates the
amount of total text in the area displayed, including the hidden parts
of the outline.

    In other words, what the thumb seems to measure is the proportion of
    total (visible or invisible) text between top and bottom of the screen
    compared to the total text in the buffer. 

    This seems to be the behavior in Emacs 20.7 with native scrollbars, as
    well as in the current 21.3.50 CVS, both with native 
    (./configure --without-toolkit-scroll-bars) and with Xaw3d (no options
    to configure) scroll bars.

That is the way it should work.

      Basically, the scrollbar should be based on
    "number of vertical pixels" rather than "number of chars", but
    given the current way Emacs is written, it's basically impossible
    to do.

Basing it on pixels would be consistent behavior, but (as you said) it
isn't feasible.  For Emacs to do this computation for the whole
of a long buffer would take much too long.

    3) Updating thumb size while dragging
       That just seems irritating.  If a user selcts the bottom of a
       large thumb at the start of the drag then the thumb shrinks they
       end up in an odd position.

This seems to be a case where all alternatives are flawed.  I agree
that changing the thumb size while dragging would look strange--but if
you don't change the thumb size while dragging, it has to change when
you stop dragging, and that would look strange.

I don't yet have an opinion about which one is better.