bug#32002: 24.4; Scroll bar start, end not correct

[Eli Zaretskii]

On July 4, 2018 8:13:01 AM GMT+03:00, Mike Kupfer <mkupfer@alum.berkeley.edu> 
wrote:
> Andrew Kurn wrote:
> 
> > Anyhow, my contention is that, since the whole buffer is on display,
> > the scroll bar should extend over the whole window.  The length of
> the
> > scroll bar, as a fraction of the window height, is supposed to be
> the
> > fraction of the buffer on display.  Its top is the character (line,
> > usually) where the display starts.  Its bottom is where it stops.
> 
> That's what I would expect, too.  The current behavior was explained
> to
> me as deliberate, to account for differences in scrolling behavior
> when
> comparing Emacs to GTK apps like gedit.  That is, when you get to the
> end of a file in gedit, the last line of the file is at the bottom of
> the window.  If you get to the bottom of the file and continue to
> press
> PgDown or the down arrow key, gedit just beeps at you.
> 
> With Emacs, though, it is possible, using PgDown or C-v, to scroll
> down
> so that the last line of the file appears higher up in the window,
> possibly even at the very top of the window.
> 
> There does seem to be an inconsistency between the scrollbar and
> scrolling using keypresses.  For example, in the attached screenshot,
> if
> I try to scroll using PgDown, C-v, or down arrow, I get an "End of
> buffer" error.  Yet I can scroll down using the down-stepper on the
> scrollbar.  And if I drag the scrollbar marker down as far as it will
> go, the text scrolls off the top, leaving me with a blank window.
> 
> Personally, I find the gap below the scrollbar marker disorienting; I
> can't trust the scrollbar to show me when I'm at the end of the file.
> This is annoying enough that I try to avoid Emacs+GTK.
> 
> mike

C-v scrolls by a window-full, that's why it signals an error.
Try "C-u 1 C-v" instead.  That's what the down-stepper
does, so there's no inconsistency here.