Re: Addition to emacsbug.el

["Jan D." <jan.h.d@swipnet.se>]

>>> 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.
>
> I haven't really tested to see where the threshold is for me, but I 
> think
> that sounds reasonable.
>
>>
>>> Otherwise we should do something else, be it your solution or the 
>>> thumb
>>> shrinking one.
>>>

Actually, after thinking a bit, how about this approach:

If the buffer is large enough (for some definition of enough), use the 
virtual page scrolling (as GTK uses today).

If the scroll thumb is not at the bottom (i.e. no overscrolling), 
scroll as normal (i.e. no shrinking thumb to 0).

If the scroll thumb is at the bottom, shrink the thumb to 0.

That way it is easier for a user to see that you can actually 
overscroll, it is not apparent otherwise.

	Jan D.