Re: Addition to emacsbug.el

[Stefan]

>> Well, it's a question of taste, obviously.  I myself introduced the idea
>> of "empty virtual page" in the Xaw3d code (so if you're looking at a 25
>> lines buffer in a 25-lines window, the thumb is only covering half of the
>> scrollbar).  But after using it for a while I decided I didn't like it
>> because I was never sure whether there was still something left in the
>> buffer (typically when reading Gnus messages).  There are various ways to
>> provide some other visual feedback, but experience showed that the
>> scrollbar is the feedback that I use.

> For GTK at least some compromise is needed.  Some themes have a minimum
> size for the thumb.  So if the thumb is at its minimum size
> the overscrolling with the thumb shrinking can't happen.

Huh?  Are you sure?  I'd expect that the display-size of the thumb is
"unrelated" to the size as specified by the C code.  What if your document
is made of 10 pages and your scrollbar is 40 pixels and your minimum thumb
size is 20 pixels, is GTK going to prevent you from seeing more than
2 pages?

> If the shown portion of the buffer is small compared to the total size of
> the buffer, I think the virtual page behaviour is OK.  After all, can you
> see the difference between a thumb who has a height that is 1/30 of the
> window height, or 1/31?

Agreed: the exact size of the thumb doesn't matter that much.

But I can usually still see whether the thumb is "at the bottom" or whether
there's still one or 2 pixels left, so as long as 1 pixels represents about
20 lines the difference is "relevant" (i.e. 20 lines =~ 500 chars =>
a buffer of about 500B * 1000 pixels = 500KB for my typical frames).

By "relevant" I don't mean important, but just that it's not 100%
negligeable.  I could probably happily live with the "virtual extra page"
for buffers as small as 50KB.

> Otherwise we should do something else, be it your solution or the thumb
> shrinking one.

I don't know what is the "thumb shrinking" solution.

> To change the thumb size means fiddling with the page size and the maximum
> values for the scroll bar.  Relating values back to a buffer position then
> becomes so much harder.  Not impossible, but certainly a lot of testing
> needs to be done.

Hmm... I'll trust you on that one because I obviously don't understand
the difficulty: the way the xterm.c code uses SB_MAX or equivalent as the
"maximum value" it would work exactly the same whether SB_MAX is a constant
or not.

> There is another thing I noticed about your patch.  If the buffer contains
> three lines and the window is 34 lines, the thumb covers the whole window.
> Now, if I start to scroll down putting the pointer somewhere at the top
> of the thumb, I'll have to move down to half the window before one line
> is actually scrolled.  Then down to 3/4 before the second line is scrolled
> and finally to the bottom to get the third line to scroll.

> Now, if I start with the pointer near the bottom of the thumb, the two
> first lines are scrolled just by moving the pointer one pixel.

> I think the amount you move the pointer should determine how many lines
> are scrolled, not where you happen to put the pointer when you start.
> Also, the amount to move for scrolling one line should be the same
> regardless of the size of the buffer or the amount show.

Well, obviously this actually depends on the toolkit in use (in Xaw3d, the
thumb is always moved to the mouse pointer during grab, so the position of
the mouse pointer is what matters, rather than the distance you move it).
What toolkit were you using in the above described case?
My patch is only really tested with Xaw3d.

> The code shared is smaller than the code that differs, so I really don't
> see the point.  But if the shared code could go into a function of its
> own that would make sense.  For GTK it was convinient to have all code
> that modifies the scroll bars in one file when changes had to be done.

Well, I was hoping the code that differs could be reduced further (I didn't
have GTK installed when I did the merge, so I didn't get to check whether
it compiled, and I haven't tried to change the code to adapt to the "squash
thumb to 0-size during drag" to GTK: this change has reduced the
code-difference between Xaw3d and Motif (and non-toolkit) to one or two
lines only, so I'm hoping something similar can happen with GTK).


        Stefan