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

[Mike Kupfer <mkupfer@alum.berkeley.edu>]

Eli Zaretskii wrote:

> > From: Mike Kupfer <mkupfer@alum.berkeley.edu>
> > cc: Andrew Kurn <kurn@sfu.ca>, 32002@debbugs.gnu.org
> > Date: Fri, 13 Jul 2018 21:56:40 -0700
> > 
> > With
> > 
> >   (setq scroll-bar-adjust-thumb-portion nil)
> > 
> > the thumb takes up the entire track.  (I'm doing this testing with a
> > theme that lacks steppers.)  Moving the mouse down (while holding
> > button1) does not move the thumb, but it does cause the text to scroll
> > up.  Moving the mouse up (while holding button1) does not cause the text
> > to reappear, even if I move the mouse all the way to the top of the
> > thumb.
[...]
> Which part of scroll-bar-toolkit-scroll gets executed when you move
> the thumb up, after scrolling the entire text out of the window?
[...]

It's

	 ((eq part 'handle)
	  (scroll-bar-drag-1 event))))

> [...] in which case I think the problem is in
> scroll-bar-drag-1.  Can you spot it?  I think it calculates the new
> starting point of the window incorrectly, because it doesn't take into
> account the special situation with scroll-bar-adjust-thumb-portion in
> this particular case.

What I see is that in scroll-bar-drag-1, portion-whole is (1 . 1), both
when I drag the mouse down and when I drag it up.  So scroll-bar-drag-1
always does (goto-char (point-max)).

Should scroll-bar-drag-1 be doing the correction to account for
scroll-bar-adjust-thumb-portion, or should that be done higher up the
stack?  (If scroll-bar-drag-1 needs to apply a correction, then I
suspect there are other functions that also need to apply a correction.
Perhaps it would be cleaner to make the correction early on, so that it
only needs to be done once.  But I'm not familiar with the code, so
there may well be aspects to this that I'm missing.)

mike