I can't remember if this has ever worked in GNU Emacs 24, but shouldn't the scroll bar fill out the entire window when the buffer (file) shown is shorter than the window?
The first example is the splash screen (I am starting emacs with
--no-init-file --no-site-file --no-site-lisp to avoid any interference from local configuration).
Ok, maybe the splash screen is special – it has an image and different types of fonts.
Let us take a look at the *scratch* buffer instead, that is simple, only 4 lines.
Other programs using GTK scroll bars can do this, why not GNU Emacs 24?
Here is the bug reported against 23.0.60: bug#1036 - unfortunately the reply is a little terse. I wonder if there is a bug registered on GTK for fixing this; maybe a work-around can be developed? What do people do? Compile GNU Emacs without GTK?
Only a dozen or more emails into the 2003 thread, I am surprised at how much the focus is on the least - to me anyway - interesting thing: What happens when you scroll past the end. I don't care, I just want to be able to reliably use the scroll bar as a gauge of how much of the buffer is in view...
Ok, so it seems if I can turn overscrolling off, I would be happy. I never use that, and that looks like it is the reason for the weirdly sized scroll bar. Google wasn't of help in this, so I have turned to Stackoverflow.
Update: I have compiled emacs with the patch suggested on emacs-devel in 2009, and that works – in that the scroll bar is 100% high if the entire buffer can be shown. If I use the scroll bar to scroll down, I can't scroll up again, but I rarely, if ever, scroll by using the mouse, so it is a non-issue for me.
Perhaps the constant "30" seen in the patch could be a variable that could be configured in emacs, so the default could be 30 and I could set it to 0?
Update 2: No, that doesn't work, apparently calling WINDOW_TOTAL_LINES() affects the scrollbar even if portion is 0; but avoiding the block of code entirely depending on a variable is doable.
Update 3: Ok, a patch that only handles GTK is too narrow. Let me try a patch that handles both toolkits that use the "* 30" idea. I probably should have addressed the "and share more of the code, as well" part of the comment in my patch, as well... ⊗