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

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

[Andrew Kurn]

--text follows this line--

When I start Emacs (even with -Q) the scroll bar does not
properly reflect the part of the buffer displayed on the screen.

If the first visible line of text is at 30% of the buffer then
the top of the scroll bar should be 30% of the way from the
top of the window.  Similarly for the bottom.

If all the buffer is on display, the scroll bar should run
the full length of the window.

. . . I don't suppose this is news to anyone, but it has
been wrong through many versions of Emacs.

Time it was fixed.

Love and kisses,
Andrew




In GNU Emacs 24.4.1 (i586-pc-linux-gnu, GTK+ Version 3.14.5)
 of 2017-09-12 on x86-csail-01, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11604000
System Description:	Debian GNU/Linux 8.10 (jessie)

Configured using:
 `configure --build i586-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
 --build i586-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security -Wall' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-z,relro'

Important settings:
  value of $LANG: en_CA.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <menu-bar> <help-menu> <se
nd-emacs-bug-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 8 71210 8008)
 (symbols 24 17572 0)
 (miscs 20 35 146)
 (strings 16 9032 3757)
 (string-bytes 1 247513)
 (vectors 8 8911)
 (vector-slots 4 388025 6400)
 (floats 8 63 232)
 (intervals 28 218 16)
 (buffers 512 11)
 (heap 1024 41697 616))

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

[Eli Zaretskii]

> Date: Fri, 29 Jun 2018 00:36:02 -0700
> From: Andrew Kurn <kurn@sfu.ca>
> 
> If the first visible line of text is at 30% of the buffer then
> the top of the scroll bar should be 30% of the way from the
> top of the window.  Similarly for the bottom.
> 
> If all the buffer is on display, the scroll bar should run
> the full length of the window.

Is this not so if you count percents in terms of characters (as
opposed to lines)?  Because that's what Emacs does.

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

[Eli Zaretskii]

[Please keep the bug address on the CC list.]

> Date: Fri, 29 Jun 2018 09:24:02 -0700
> From: Andrew Kurn <kurn@sfu.ca>
> 
> > Is this not so if you count percents in terms of characters (as
> > opposed to lines)?  Because that's what Emacs does.
> 
> Yes, no, it's wrong even by characters.
> 
> For instance, when you start up, *scratch* has 3 lines in it;
> the whole thing is on display.  But the scroll bar only
> reaches half-way down the window.

I guess it's GTK-specific, then.  Something related to scaling,
perhaps?

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

[Andrew Kurn]

On Fri 29 Jun 2018 20:24 +0300, Eli Zaretskii wrote:

> [Please keep the bug address on the CC list.]
Sorry.


> 
> > Date: Fri, 29 Jun 2018 09:24:02 -0700
> > From: Andrew Kurn <kurn@sfu.ca>
> > 
> > > Is this not so if you count percents in terms of characters (as
> > > opposed to lines)?  Because that's what Emacs does.
> > 
> > Yes, no, it's wrong even by characters.
> > 
> > For instance, when you start up, *scratch* has 3 lines in it;
> > the whole thing is on display.  But the scroll bar only
> > reaches half-way down the window.
> 
> I guess it's GTK-specific, then.  Something related to scaling,
> perhaps?
> 

I'm not sure whether it speaks to the issue, but the same problem
appears when I'm using JWM (Joe's Window Manager) and Arch.

I do notice that when I pull the scroll bar down to the bottom
of the window that all the text disappears off the top.
So it occurs to me that this might be a mis-feature, rather
than an out-and-out bug.

If so, perhaps you can advise me how to turn it off.  Usually
the Emacs community is good enough to provide a way of
disabling such features.

Andrew

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

[Glenn Morris]

>> I guess it's GTK-specific, then.  Something related to scaling,
>> perhaps?
[...]
> If so, perhaps you can advise me how to turn it off.  Usually
> the Emacs community is good enough to provide a way of
> disabling such features.

You can try building Emacs using --without-toolkit-scroll-bars.
(Despite the misleading --help text, this also affects GTK builds.)
Otherwise I imagine Emacs has no way to customize how GTK scroll bars work.

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

[Glenn Morris]

PS or you can try a different toolkit altogether, eg "apt install
emacs24-lucid".

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

[Andrew Kurn]

On Mon  2 Jul 2018 14:16 -0400, Glenn Morris wrote:
> 
> >> I guess it's GTK-specific, then.  Something related to scaling,
> >> perhaps?
> [...]
> > If so, perhaps you can advise me how to turn it off.  Usually
> > the Emacs community is good enough to provide a way of
> > disabling such features.
> 
> You can try building Emacs using --without-toolkit-scroll-bars.
> (Despite the misleading --help text, this also affects GTK builds.)
> Otherwise I imagine Emacs has no way to customize how GTK scroll bars work.

> PS or you can try a different toolkit altogether, eg "apt install emacs24-lucid".

Um.

Just to be clear:  You guys can't reproduce the bug?

The fact that pulling the scroll bar down to the bottom
of the screen just clears the screen tells me that the
scroll bar is being calculated as if the total buffer
were the text /plus/ a screen-full of blank lines.

/That/ speaks to me of bad data being passed to GTK,
not a bug in GTK.

It seems related, also, to the fact that the percentage
calculated for the mode line is calculated using the
/first/ character on the screen, not the middle --
which would be a more intuitive number. . . .

So I would look where that number is calculated, not at
GTK . . .

. . . in my humble opinion.

Perhaps I should start another bug on this second issue,
but it does seem to me that the two problems are intimately
related.

Andrew

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

[Noam Postavsky]

[-- Attachment #1: Type: text/plain, Size: 171 bytes --]

Andrew Kurn <kurn@sfu.ca> writes:

> Just to be clear:  You guys can't reproduce the bug?

Here's a screenshot of my gtk build, the scrollbar looks the right size
to me.


[-- Attachment #2: screenshot of scratch in gtk emacs --]
[-- Type: image/png, Size: 47281 bytes --]

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

[Andrew Kurn]

On Tue  3 Jul 2018 22:00 -0400, Noam Postavsky wrote:
> 
> Andrew Kurn <kurn@sfu.ca> writes:
> 
> > Just to be clear:  You guys can't reproduce the bug?
> 
> Here's a screenshot of my gtk build, the scrollbar looks the right size
> to me.
> 


Aha!  In this we disagree.  I wonder if the others share your
opinion.

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.

Do you see what I'm talking about?  --  even if you don't agree.

Andrew

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

[Eli Zaretskii]

On July 4, 2018 6:45:41 AM GMT+03:00, Andrew Kurn <kurn@sfu.ca> wrote:
> On Tue  3 Jul 2018 22:00 -0400, Noam Postavsky wrote:
> > 
> > Andrew Kurn <kurn@sfu.ca> writes:
> > 
> > > Just to be clear:  You guys can't reproduce the bug?
> > 
> > Here's a screenshot of my gtk build, the scrollbar looks the right
> size
> > to me.
> > 
> 
> 
> Aha!  In this we disagree.  I wonder if the others share your
> opinion.
> 
> 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.
> 
> Do you see what I'm talking about?  --  even if you don't agree.
> 
> Andrew

I think we support both those who share this opinion and
those who don't.  It sounds like you want to set
scroll-bar-adjust-thumb-portion to nil.

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

[Mike Kupfer]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

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

[-- Attachment #2: Emacs at end-of-file --]
[-- Type: image/png, Size: 45698 bytes --]

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.

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

[Mike Kupfer]

Eli Zaretskii wrote:

> 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.

Ah!  Yes, that works.  Thanks for that and for the pointer to
scroll-bar-adjust-thumb-portion.

Though using the Emacs 25 in Debian stable (25.1) and testing (25.2),
the stepper buttons don't seem to be behaving quite right.

With (setq scroll-bar-adjust-thumb-portion t):

  If I go to the bottom of my ~/.profile and start clicking on the
  up-stepper, the text will scroll, but the amount it moves varies from
  0 to 2 lines.  (I expect it to scroll 1 line per click.)

With (setq scroll-bar-adjust-thumb-portion nil):

  If I go to the bottom of my ~/.profile using M->, the last line of the
  file is a couple lines from the bottom of the window.  If I click once
  on the up-stepper, I expect the last line to move closer to the bottom
  of the window.  Instead, it jumps to the top of the window.

If I have time today, I'll try building Emacs 26 with GTK to see if it
behaves any better.

mike

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

[Mike Kupfer]

Mike Kupfer wrote:

> With (setq scroll-bar-adjust-thumb-portion t):
> 
>   If I go to the bottom of my ~/.profile and start clicking on the
>   up-stepper, the text will scroll, but the amount it moves varies from
>   0 to 2 lines.  (I expect it to scroll 1 line per click.)
> 
> With (setq scroll-bar-adjust-thumb-portion nil):
> 
>   If I go to the bottom of my ~/.profile using M->, the last line of the
>   file is a couple lines from the bottom of the window.  If I click once
>   on the up-stepper, I expect the last line to move closer to the bottom
>   of the window.  Instead, it jumps to the top of the window.
> 
> If I have time today, I'll try building Emacs 26 with GTK to see if it
> behaves any better.

I'm afraid the emacs-26 branch behaves the same as Emacs 25.

mike

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

[Noam Postavsky]

Mike Kupfer <mkupfer@alum.berkeley.edu> writes:

> Mike Kupfer wrote:
>
>> With (setq scroll-bar-adjust-thumb-portion t):
>> 
>>   If I go to the bottom of my ~/.profile and start clicking on the
>>   up-stepper, the text will scroll, but the amount it moves varies from
>>   0 to 2 lines.  (I expect it to scroll 1 line per click.)
>> 
>> With (setq scroll-bar-adjust-thumb-portion nil):
>> 
>>   If I go to the bottom of my ~/.profile using M->, the last line of the
>>   file is a couple lines from the bottom of the window.  If I click once
>>   on the up-stepper, I expect the last line to move closer to the bottom
>>   of the window.  Instead, it jumps to the top of the window.
>> 
>> If I have time today, I'll try building Emacs 26 with GTK to see if it
>> behaves any better.
>
> I'm afraid the emacs-26 branch behaves the same as Emacs 25.

I don't understand what this "up-stepper" you are talking about is.

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

[Mike Kupfer]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

Noam Postavsky wrote:

> I don't understand what this "up-stepper" you are talking about is.

Steppers are the up and down arrows that appear at the top and bottom of
the scrollbar.  You can see them in the attached screenshot.  They are
only present in some themes, like Menta and Clearlooks-Phenix.  Notably,
Adwaita (the default GTK3 theme) does not have steppers.

It's possible to do some CSS hacking to get steppers with Adwaita, but I
believe the syntax depends on which version of GTK3 you're using.

mike


[-- Attachment #2: Emacs, GTK3, Menta theme --]
[-- Type: image/png, Size: 45698 bytes --]

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

[Eli Zaretskii]

> From: Mike Kupfer <mkupfer@alum.berkeley.edu>
> cc: 32002@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>, kurn@sfu.ca
> Date: Wed, 04 Jul 2018 16:56:13 -0700
> 
> Steppers are the up and down arrows that appear at the top and bottom of
> the scrollbar.  You can see them in the attached screenshot.  They are
> only present in some themes, like Menta and Clearlooks-Phenix.  Notably,
> Adwaita (the default GTK3 theme) does not have steppers.
> 
> It's possible to do some CSS hacking to get steppers with Adwaita, but I
> believe the syntax depends on which version of GTK3 you're using.

What Emacs does is call

  (scroll-up +/-1)

for each input event that comes from the scroll bar's "steppers".  So
the only way I can explain why you see scrolling of more than 1 line
is that the GTK scroll bar sends more than one event.  Or maybe it
doesn't send the 'up and 'down parts in the event for some reason.
Stepping with Edebug through scroll-bar-toolkit-scroll should show
what's going on there.

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

[Mike Kupfer]

Eli Zaretskii wrote:

> What Emacs does is call
> 
>   (scroll-up +/-1)
> 
> for each input event that comes from the scroll bar's "steppers".
[...]
> Stepping with Edebug through scroll-bar-toolkit-scroll should show
> what's going on there.

When I click on either stepper, one event gets passed to
scroll-bar-toolkit-scroll.  It looks like

  (mouse-1 (#<window 3 on .profile> vertical-scroll-bar (5637316 . 7584542) 0 handle))

(There is some variance in the numbers in the (5637316 . 7584542) part.)

So scroll-bar-drag-1 gets called, rather than scroll-up.

mike

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

[Eli Zaretskii]

On July 5, 2018 8:28:28 AM GMT+03:00, Mike Kupfer <mkupfer@alum.berkeley.edu> wrote:
> Eli Zaretskii wrote:
> 
> > What Emacs does is call
> > 
> >   (scroll-up +/-1)
> > 
> > for each input event that comes from the scroll bar's "steppers".
> [...]
> > Stepping with Edebug through scroll-bar-toolkit-scroll should show
> > what's going on there.
> 
> When I click on either stepper, one event gets passed to
> scroll-bar-toolkit-scroll.  It looks like
> 
> (mouse-1 (#<window 3 on .profile> vertical-scroll-bar (5637316 .
> 7584542) 0 handle))
> 
> (There is some variance in the numbers in the (5637316 . 7584542)
> part.)
> 
> So scroll-bar-drag-1 gets called, rather than scroll-up.
> 
> mike

According to xg_scroll_callback, GTK is supposed to provide
the up and down events, so perhaps some more debugging is
required.

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

[Mike Kupfer]

Eli Zaretskii wrote:

> According to xg_scroll_callback, GTK is supposed to provide
> the up and down events, so perhaps some more debugging is
> required.

Yeah, I guess the next step is to run Emacs under gdb and see what's
getting passed to xg_scroll_callback().  I looked at the code for
xg_scroll_callback(), and it certainly looks straightforward enough.

thanks,
mike

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

[Mike Kupfer]

Mike Kupfer wrote:

> Yeah, I guess the next step is to run Emacs under gdb and see what's
> getting passed to xg_scroll_callback().

gdb says that Emacs is getting jump events, not step events.

  Thread 1 "emacs" hit Breakpoint 1, xg_scroll_callback (range=0x2f58740, 
      scroll=GTK_SCROLL_JUMP, value=5637316.2000000002, 
      user_data=0x1493c30 <bss_sbrk_buffer+8990864>) at xterm.c:5644

mike

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

[Eli Zaretskii]

> From: Mike Kupfer <mkupfer@alum.berkeley.edu>
> cc: npostavs@gmail.com, 32002@debbugs.gnu.org, kurn@sfu.ca
> Date: Thu, 05 Jul 2018 20:58:38 -0700
> 
> gdb says that Emacs is getting jump events, not step events.
> 
>   Thread 1 "emacs" hit Breakpoint 1, xg_scroll_callback (range=0x2f58740, 
>       scroll=GTK_SCROLL_JUMP, value=5637316.2000000002, 
>       user_data=0x1493c30 <bss_sbrk_buffer+8990864>) at xterm.c:5644

Thanks.  I guess the issue now moves to GTK-land: why do we get jump
events when you click on the steppers?  Maybe someone who knows GTK
can answer that.

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

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Mike Kupfer <mkupfer@alum.berkeley.edu>
>> cc: npostavs@gmail.com, 32002@debbugs.gnu.org, kurn@sfu.ca
>> Date: Thu, 05 Jul 2018 20:58:38 -0700
>> 
>> gdb says that Emacs is getting jump events, not step events.
>> 
>>   Thread 1 "emacs" hit Breakpoint 1, xg_scroll_callback (range=0x2f58740, 
>>       scroll=GTK_SCROLL_JUMP, value=5637316.2000000002, 
>>       user_data=0x1493c30 <bss_sbrk_buffer+8990864>) at xterm.c:5644
>
> Thanks.  I guess the issue now moves to GTK-land: why do we get jump
> events when you click on the steppers?  Maybe someone who knows GTK
> can answer that.

It looks like GTK sends GTK_SCROLL_JUMP everytime the position of the
scrollbar thumb is changed, regardless of how you change it. I think
it can *also* send events when you click the stepper, but I suspect
you then get two events, with no easy way to distinguish them. Iʼd
test, but my theme doesnʼt have steppers.

Robert

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

[martin rudalics]

 >>> gdb says that Emacs is getting jump events, not step events.
 >>>
 >>>    Thread 1 "emacs" hit Breakpoint 1, xg_scroll_callback (range=0x2f58740,
 >>>        scroll=GTK_SCROLL_JUMP, value=5637316.2000000002,
 >>>        user_data=0x1493c30 <bss_sbrk_buffer+8990864>) at xterm.c:5644
 >>
 >> Thanks.  I guess the issue now moves to GTK-land: why do we get jump
 >> events when you click on the steppers?  Maybe someone who knows GTK
 >> can answer that.
 >
 > It looks like GTK sends GTK_SCROLL_JUMP everytime the position of the
 > scrollbar thumb is changed, regardless of how you change it. I think
 > it can *also* send events when you click the stepper, but I suspect
 > you then get two events, with no easy way to distinguish them. Iʼd
 > test, but my theme doesnʼt have steppers.

Here I'm called back with exactly one GTK_SCROLL_STEP notification as

#0  xg_scroll_callback (range=0x183a3b0, scroll=GTK_SCROLL_STEP_FORWARD, value=244073, user_data=0x15410a0) at ../../src/xterm.c:5673

Otherwise, IIUC nothing would happen since GTK_SCROLL_JUMP expects
that the mouse has been grabbed in order to send a scroll_bar_event.
But maybe I'm misreading the code.

martin

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

[Eli Zaretskii]

> Date: Fri, 06 Jul 2018 14:56:10 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Mike Kupfer <mkupfer@alum.berkeley.edu>, 32002@debbugs.gnu.org, 
>  kurn@sfu.ca, npostavs@gmail.com
> 
>  >>> gdb says that Emacs is getting jump events, not step events.
>  >>>
>  >>>    Thread 1 "emacs" hit Breakpoint 1, xg_scroll_callback (range=0x2f58740,
>  >>>        scroll=GTK_SCROLL_JUMP, value=5637316.2000000002,
>  >>>        user_data=0x1493c30 <bss_sbrk_buffer+8990864>) at xterm.c:5644
>  >>
>  >> Thanks.  I guess the issue now moves to GTK-land: why do we get jump
>  >> events when you click on the steppers?  Maybe someone who knows GTK
>  >> can answer that.
>  >
>  > It looks like GTK sends GTK_SCROLL_JUMP everytime the position of the
>  > scrollbar thumb is changed, regardless of how you change it. I think
>  > it can *also* send events when you click the stepper, but I suspect
>  > you then get two events, with no easy way to distinguish them. Iʼd
>  > test, but my theme doesnʼt have steppers.
> 
> Here I'm called back with exactly one GTK_SCROLL_STEP notification as
> 
> #0  xg_scroll_callback (range=0x183a3b0, scroll=GTK_SCROLL_STEP_FORWARD, value=244073, user_data=0x15410a0) at ../../src/xterm.c:5673

So maybe the GTK version is a factor here?

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

[martin rudalics]

 >> Here I'm called back with exactly one GTK_SCROLL_STEP notification as
 >>
 >> #0  xg_scroll_callback (range=0x183a3b0, scroll=GTK_SCROLL_STEP_FORWARD, value=244073, user_data=0x15410a0) at ../../src/xterm.c:5673
 >
 > So maybe the GTK version is a factor here?

I can't spot anything in the GTK sources that would confirm that.

martin

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

[Eli Zaretskii]

> Date: Sat, 07 Jul 2018 09:15:16 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: rpluim@gmail.com, mkupfer@alum.berkeley.edu, 32002@debbugs.gnu.org, 
>  kurn@sfu.ca, npostavs@gmail.com
> 
>  >> Here I'm called back with exactly one GTK_SCROLL_STEP notification as
>  >>
>  >> #0  xg_scroll_callback (range=0x183a3b0, scroll=GTK_SCROLL_STEP_FORWARD, value=244073, user_data=0x15410a0) at ../../src/xterm.c:5673
>  >
>  > So maybe the GTK version is a factor here?
> 
> I can't spot anything in the GTK sources that would confirm that.

Then it should be something in the system configuration/setup?  Some
GTK config file or system-wide setting, perhaps, like something
imposed by the installed desktop?  What else can explain such clear
differences in behavior between different systems?

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

[martin rudalics]

 > Then it should be something in the system configuration/setup?  Some
 > GTK config file or system-wide setting, perhaps, like something
 > imposed by the installed desktop?  What else can explain such clear
 > differences in behavior between different systems?

Maybe Mike's theme doesn't show the arrow keys or the mouse position
gets interpreted wrongly.  At least his "right-click in the scrollbar
above or below the thumb (slider)" is a misinterpretation of how
scroll bars are supposed to behave.  Such clicks should be interpreted
as "jumps" as I tried to explain elsewhere.

martin

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

[Mike Kupfer]

martin rudalics wrote:

> Maybe Mike's theme doesn't show the arrow keys or the mouse position
> gets interpreted wrongly.

I'm not sure what you mean by "arrow keys".  Is this the same thing as
the "stepper buttons" I've been referring to?

> At least his "right-click in the scrollbar
> above or below the thumb (slider)" is a misinterpretation of how
> scroll bars are supposed to behave.  Such clicks should be interpreted
> as "jumps" as I tried to explain elsewhere.

https://developer.gnome.org/gtk3/stable/GtkScrollbar.html is the closest
I've found to documentation on how a (GTK3) scrollbar is supposed to
behave.  I do not see that it says what should happen if the user
right-clicks.  So I am not convinced that I have misinterpreted
anything.  I did test my right-click idea on gedit before posting it,
and a single right-click in the scroll area behaved the same as
left-clicking on the corresponding stepper button.

I have found some discussion at
https://bugzilla.redhat.com/show_bug.cgi?id=1495520, which suggests that
right-click is intended for smooth scrolling--at least in some versions
of GTK3.  And I see that right-click-and-hold does produce smooth
scrolling on gedit, though I'm unable to get the variable-speed effect
mentioned at https://bugzilla.redhat.com/show_bug.cgi?id=1495520#c9.

Could it make a difference that I've been using MATE and Cinnamon for
testing?

Anyway, my original comments were about the behavior of Emacs when I
click on a stepper button.  I would be happy to limit future discussion
to that use case.

mike

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

[Eli Zaretskii]

> cc: Eli Zaretskii <eliz@gnu.org>, rpluim@gmail.com, 32002@debbugs.gnu.org,
>         kurn@sfu.ca, npostavs@gmail.com
> From: Mike Kupfer <mkupfer@alum.berkeley.edu>
> Date: Sat, 07 Jul 2018 08:19:30 -0700
> 
> martin rudalics wrote:
> 
> > Maybe Mike's theme doesn't show the arrow keys or the mouse position
> > gets interpreted wrongly.
> 
> I'm not sure what you mean by "arrow keys".  Is this the same thing as
> the "stepper buttons" I've been referring to?

Yes.

> Could it make a difference that I've been using MATE and Cinnamon for
> testing?

Maybe, I don't know.  Maybe someone else could try reproducing yuour
problem in the same environment.

> Anyway, my original comments were about the behavior of Emacs when I
> click on a stepper button.  I would be happy to limit future discussion
> to that use case.

I thought we were talking about that use case.  As long as Emacs gets
the STEP event, it works correctly.  The problem is to understand why
in your case we get a different event.

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

[Mike Kupfer]

Eli Zaretskii wrote:

> As long as Emacs gets
> the STEP event, it works correctly.  The problem is to understand why
> in your case we get a different event.

FWIW, I built the emacs-26 branch on Debian 8 (libgtk 3.14.5), and there
the stepper works correctly.

mike

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

[Mike Kupfer]

Mike Kupfer wrote:

> FWIW, I built the emacs-26 branch on Debian 8 (libgtk 3.14.5), and there
> the stepper works correctly.

And on Xubuntu 16.04, the bundled Emacs uses GTK 3.18.9, and there I get
the unwanted behavior.

Some web searching led me to the GTK project's NEWS file on GitHub[1],
which has a couple entries that caught my eye.

  Overview of Changes in GTK+ 3.17.5
  ==================================
  [...]
  
  * GtkScrolledWindow
   [...]
   - Switch the roles of secondary and middle click on scrollbar steppers
     - Primary click starts low-speed autoscrolling
     - Secondary click start high-speed autoscrolling
     - Middle click scrolls to the end
   - Tweak button bindings on scrollbars (and scales)
     - Primary click warps to the location
     - Primary click with Shift jumps by pages
   - Secondary click starts variable-speed autoscrolling
  
  
  Overview of Changes in GTK+ 3.15.9
  ==================================
  
  * GtkScrolledWindow
   [...]
   - Make steppers use smooth autoscrolling

I suppose that since these entries refer to GtkScrolledWindow, rather
than GtkScrollbar, these NEWS entries do not prove that the behavior of
the scrollbar widget itself has changed.  But it looks suspicious to me.

mike

[1] https://github.com/GNOME/gtk/blob/faba0f0145b1281facba20fb90699e3db594fbb0/NEWS

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

[Mike Kupfer]

Mike Kupfer wrote:

> I did test my right-click idea on gedit before posting it,
> and a single right-click in the scroll area behaved the same as
> left-clicking on the corresponding stepper button.

It occurs to me I haven't been precise enough in testing or describing
the behavior of gedit using stepper buttons.  I thought I was getting
one line of scroll per click, but it actually varies somewhat:
partial-lines scrolls are possible, and the amount of scroll depends on
how quickly I do the click.  So maybe the stepper buttons are being used
for smooth-scroll?  This is with libgtk3 3.22.11 on Debian 9.

mike

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

[martin rudalics]

 >> Maybe Mike's theme doesn't show the arrow keys or the mouse position
 >> gets interpreted wrongly.
 >
 > I'm not sure what you mean by "arrow keys".  Is this the same thing as
 > the "stepper buttons" I've been referring to?

Yes.  I'll call them stepper buttons from now on.

 >> At least his "right-click in the scrollbar
 >> above or below the thumb (slider)" is a misinterpretation of how
 >> scroll bars are supposed to behave.  Such clicks should be interpreted
 >> as "jumps" as I tried to explain elsewhere.
 >
 > https://developer.gnome.org/gtk3/stable/GtkScrollbar.html is the closest
 > I've found to documentation on how a (GTK3) scrollbar is supposed to
 > behave.  I do not see that it says what should happen if the user
 > right-clicks.  So I am not convinced that I have misinterpreted
 > anything.  I did test my right-click idea on gedit before posting it,
 > and a single right-click in the scroll area behaved the same as
 > left-clicking on the corresponding stepper button.
 >
 > I have found some discussion at
 > https://bugzilla.redhat.com/show_bug.cgi?id=1495520, which suggests that
 > right-click is intended for smooth scrolling--at least in some versions
 > of GTK3.  And I see that right-click-and-hold does produce smooth
 > scrolling on gedit, though I'm unable to get the variable-speed effect
 > mentioned at https://bugzilla.redhat.com/show_bug.cgi?id=1495520#c9.
 >
 > Could it make a difference that I've been using MATE and Cinnamon for
 > testing?

We first have to make sure that you indeed click on the stepper
buttons.  For this purpose please do the following with Emacs -Q:
Evaluate

M-: (setq window-min-height 1) RET
C-x 2
M-: (window-resize nil (- 2 (window-height))) RET

This should get you a one-line window on top of the frame.  Here this
window has just two small stepper buttons and no slider.  Hopefully,
yours is the same.  I wonder what scroll bars without stepper buttons
show in such a case.

Now please tell us what clicking or pressing such a button produces.
If running this under GDB reveals that in xg_scroll_callback 'scroll'
equals GTK_SCROLL_JUMP, then please tell us the values of 'whole' and
'value' in that case.

Thank you, martin

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

[Mike Kupfer]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

martin rudalics wrote:

> We first have to make sure that you indeed click on the stepper
> buttons.  For this purpose please do the following with Emacs -Q:
> Evaluate
> 
> M-: (setq window-min-height 1) RET
> C-x 2
> M-: (window-resize nil (- 2 (window-height))) RET
> 
> This should get you a one-line window on top of the frame.  Here this
> window has just two small stepper buttons and no slider.  Hopefully,
> yours is the same.

Unfortunately, not.  I initially get whitespace where the scrollbar
should be.  If I change the theme a few times, I eventually get stepper
buttons, but the slider is included, and it all extends down into the
second window (see attached).  (This is with the emacs-26 branch, built
July 4.)

> Now please tell us what clicking or pressing such a button produces.
> If running this under GDB reveals that in xg_scroll_callback 'scroll'
> equals GTK_SCROLL_JUMP, then please tell us the values of 'whole' and
> 'value' in that case.

I've attached 2 logs from the gdb session.  The first was after using
your original instructions.  The second was from using (- 3 ...) instead
of (- 2 ...).  (In the second case the scrollbar was visible, but again
it extended into the lower window.)

Let me know if I messed something up or there is additional data you
need.

thanks,
mike


[-- Attachment #2: Emacs with scrollbar --]
[-- Type: image/png, Size: 44382 bytes --]

[-- Attachment #3: gdb log, original instructions --]
[-- Type: text/plain, Size: 2911 bytes --]

stretch$ gdb /usr/new/bin/emacs
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/new/bin/emacs...done.
(gdb) break xg_scroll_callback
Breakpoint 1 at 0x4be140: file xterm.c, line 5644.
(gdb) run -Q
Starting program: /usr/new/bin/emacs -Q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe8636700 (LWP 1991)]
[New Thread 0x7fffe6748700 (LWP 1992)]
[New Thread 0x7fffe5d3a700 (LWP 1993)]

Thread 1 "emacs" hit Breakpoint 1, xg_scroll_callback (range=0x2f006f0, 
    scroll=GTK_SCROLL_JUMP, value=7069105, 
    user_data=0x1493c30 <bss_sbrk_buffer+8990864>) at xterm.c:5644
5644	{
(gdb) print *range
$1 = {widget = {parent_instance = {g_type_instance = {g_class = 0x2e20400}, 
      ref_count = 3, qdata = 0x344fd10}, priv = 0x2f00600}, priv = 0x2f00520}
(gdb) next
5648	  GtkAdjustment *adj = GTK_ADJUSTMENT (gtk_range_get_adjustment (range));
(gdb) next
5649	  struct frame *f = g_object_get_data (G_OBJECT (range), XG_FRAME_DATA);
(gdb) next
5648	  GtkAdjustment *adj = GTK_ADJUSTMENT (gtk_range_get_adjustment (range));
(gdb) next
5649	  struct frame *f = g_object_get_data (G_OBJECT (range), XG_FRAME_DATA);
(gdb) print adj
$2 = (GtkAdjustment *) 0x2fc9c80
(gdb) print *adj
$3 = {parent_instance = {g_type_instance = {g_class = 0x2cde5e0}, 
    ref_count = 1, qdata = 0x0}, priv = 0x2fc9c10}
(gdb) next
5651	  if (xg_ignore_gtk_scrollbar) return false;
(gdb) next
5653	  switch (scroll)
(gdb) next
5657	      if (FRAME_DISPLAY_INFO (f)->grabbed != 0
(gdb) next
5660		  if (bar->horizontal)
(gdb) next
5663		      whole = (int)(gtk_adjustment_get_upper (adj) -
(gdb) print whole
$4 = 0
(gdb) next
5660		  if (bar->horizontal)
(gdb) print whole
$5 = 0
(gdb) next
5671		      whole = gtk_adjustment_get_upper (adj) -
(gdb) next
5672			gtk_adjustment_get_page_size (adj);
(gdb) next
5671		      whole = gtk_adjustment_get_upper (adj) -
(gdb) next
5672			gtk_adjustment_get_page_size (adj);
(gdb) next
5673		      portion = min ((int)value, whole);
(gdb) print whole
$6 = 0
(gdb) print gtk_adjustment_get_upper(adj)
$7 = 50109456
(gdb) print gtk_adjustment_get_page_size(adj)
$8 = 50109456
(gdb) cont
Continuing.

[-- Attachment #4: gdb log (- 3 ...) --]
[-- Type: text/plain, Size: 833 bytes --]

Thread 1 "emacs" hit Breakpoint 1, xg_scroll_callback (range=0x2f58750, 
    scroll=GTK_SCROLL_JUMP, value=6164892.9000000004, 
    user_data=0x1493c30 <bss_sbrk_buffer+8990864>) at xterm.c:5644
5644	{
(gdb) next
5648	  GtkAdjustment *adj = GTK_ADJUSTMENT (gtk_range_get_adjustment (range));
(gdb) next
5649	  struct frame *f = g_object_get_data (G_OBJECT (range), XG_FRAME_DATA);
(gdb) print gtk_adjustment_get_upper(adj)
value has been optimized out
(gdb) next
5648	  GtkAdjustment *adj = GTK_ADJUSTMENT (gtk_range_get_adjustment (range));
(gdb) next
5649	  struct frame *f = g_object_get_data (G_OBJECT (range), XG_FRAME_DATA);
(gdb) next
5651	  if (xg_ignore_gtk_scrollbar) return false;
(gdb) print gtk_adjustment_get_upper(adj)
$9 = 49781840
(gdb) print gtk_adjustment_get_page_size(adj)
$10 = 49781840
(gdb) cont
Continuing.

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

[Mike Kupfer]

Mike Kupfer wrote:

> I've attached 2 logs from the gdb session.  The first was after using
> your original instructions.  The second was from using (- 3 ...) instead
> of (- 2 ...).  (In the second case the scrollbar was visible, but again
> it extended into the lower window.)

To clarify: this was after I managed to get the steppers to appear and I
clicked on the up-stepper.

If I click in the whitespace that I mentioned (no steppers, no slider),
nothing happens (the breakpoint is not triggered).

mike

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

[martin rudalics]

 > To clarify: this was after I managed to get the steppers to appear and I
 > clicked on the up-stepper.

Can you extend the slider of a two-line window's scroll bar into the
other window's scroll bar when you remove the steppers?  We could
resolve the problem simply by not drawing a slider when the window
gets too small.  But there's no way of doing that IIUC.

 > If I click in the whitespace that I mentioned (no steppers, no slider),
 > nothing happens (the breakpoint is not triggered).

Since the widget is not drawn we won't get a scroll bar event.  So
this is normal.

martin

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

[martin rudalics]

 > To clarify: this was after I managed to get the steppers to appear and I
 > clicked on the up-stepper.

Does the slider of a one-line window's scroll bar also expand into the
other window's scroll bar when you remove the steppers?

 > If I click in the whitespace that I mentioned (no steppers, no slider),
 > nothing happens (the breakpoint is not triggered).
 >> M-: (setq window-min-height 1) RET
 >> C-x 2
 >> M-: (window-resize nil (- 2 (window-height))) RET
 >>
 >> This should get you a one-line window on top of the frame.  Here this
 >> window has just two small stepper buttons and no slider.  Hopefully,
 >> yours is the same.
 >
 > Unfortunately, not.  I initially get whitespace where the scrollbar
 > should be.

Hmmm...  yes.  With GTK the scroll bar is not drawn when the minimum
slider height exceeds the window height.

 > If I change the theme a few times, I eventually get stepper
 > buttons, but the slider is included, and it all extends down into the
 > second window (see attached).  (This is with the emacs-26 branch, built
 > July 4.)

Good catch!  Apparently, our default value for the minimum height of
windows usually prevents people from seeing this.  Obviously

xg_update_scrollbar_pos (struct frame *f,
                          ptrdiff_t scrollbar_id,
                          int top,
                          int left,
                          int width,
                          int height)
[...]			
       gtk_widget_style_get (wscroll, "min-slider-length", &msl, NULL);
       bool hidden = height < msl;

is not TRT because we do not account for the sizes of the steppers
when deciding whether 'hidden' should be set.  So we would have to ask
how many steppers are present for the scroll bar in the current theme,
guess their sizes (how?) and fix the test accordingly - maybe applying
scaling as well.  I doubt it's worth the trouble because apparently
GTK intends to remove or completely rework the style stuff sooner or
later anyway.

 > Let me know if I messed something up or there is additional data you
 > need.

You did it all right.  Unfortunately, the experiment failed to find
out why you get GTK_SCROLL_JUMP events when hitting a stepper.

Is scaling at work?  When debugging xg_update_scrollbar_pos what is
the value of 'scale' after doing

       int scale = xg_get_scale (f);

One more question: Can you get a GTK_SCROLL_STEP event when the slider
is in the middle of the scroll bar such that there remains some space
between slider and the stepper buttons.  Might be the sensitivity type
of stepper arrows hurts us here.

Thanks for the experiments, martin

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

[Mike Kupfer]

[-- Attachment #1: Type: text/plain, Size: 944 bytes --]

martin rudalics wrote:

> > To clarify: this was after I managed to get the steppers to appear and I
> > clicked on the up-stepper.
> 
> Does the slider of a one-line window's scroll bar also expand into the
> other window's scroll bar when you remove the steppers?

I'm not sure how to remove the steppers other than changing the theme.

If I change the theme to Adwaita (no steppers) and follow your test
instructions, the results depend on which version of Emacs I use.  With
my emacs-26 build, I get the whitespace that I mentioned previously.  If
I use (- 3 ...) instead of (- 2 ...), giving me a 2-line window, I get a
proper scrollbar that stops at the top window's modeline (see attached).

With the Emacs 25 that is bundled with Debian 9, following your
instructions gives me a scrollbar that extends over the modeline for the
top window, but no further (see attached).

I'll get to the other experiments later, hopefully today.

mike

[-- Attachment #2: Emacs 26 Adwaita (2 lines) --]
[-- Type: image/png, Size: 51643 bytes --]

[-- Attachment #3: Emacs 25 Adwaita --]
[-- Type: image/png, Size: 42316 bytes --]

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

[martin rudalics]

 >> Does the slider of a one-line window's scroll bar also expand into the
 >> other window's scroll bar when you remove the steppers?
 >
 > I'm not sure how to remove the steppers other than changing the theme.

Changing the theme is OK.  Likely, there's no other method even via
the API.

 > If I change the theme to Adwaita (no steppers) and follow your test
 > instructions, the results depend on which version of Emacs I use.  With
 > my emacs-26 build, I get the whitespace that I mentioned previously.  If
 > I use (- 3 ...) instead of (- 2 ...), giving me a 2-line window, I get a
 > proper scrollbar that stops at the top window's modeline (see attached).
 >
 > With the Emacs 25 that is bundled with Debian 9, following your
 > instructions gives me a scrollbar that extends over the modeline for the
 > top window, but no further (see attached).

This is strange because the checks are essentially the same in Emacs 25

       if (msl > height)
         {
           /* No room.  Hide scroll bar as some themes output a warning if
              the height is less than the min size.  */
           gtk_widget_hide (wparent);
           gtk_widget_hide (wscroll);

and in Emacs 26

       bool hidden = height < msl;
       if (hidden)
         {
           /* No room.  Hide scroll bar as some themes output a warning if
              the height is less than the min size.  */
           gtk_widget_hide (wparent);
           gtk_widget_hide (wscroll);

What did change is that we now take scaling into account.  You still
didn't answer my question about whether you use scaling.  Do you?

Then it would be interesting to break at the two if tests cited above
to find out why the scroll bar is hidden for (-2 ...) in the 26 case
and not in the 25 one.  Can you post the respective values of 'height'
and 'msl'?

Thanks, martin

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

[Mike Kupfer]

martin rudalics wrote:

> Then it would be interesting to break at the two if tests cited above
> to find out why the scroll bar is hidden for (-2 ...) in the 26 case
> and not in the 25 one.  Can you post the respective values of 'height'
> and 'msl'?

Since scale is 1, do you still want this?  (It would take some time to
get the results for Emacs 25, since I don't have the source that Debian
used immediately available.)  The values for Emacs 26 are

  (gdb) print height
  $10 = 15
  (gdb) print msl
  $11 = 21

I think I'm now caught up on your requests for information.  If there's
something I missed, let me know.

thanks,
mike

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

[martin rudalics]

 >> Then it would be interesting to break at the two if tests cited above
 >> to find out why the scroll bar is hidden for (-2 ...) in the 26 case
 >> and not in the 25 one.  Can you post the respective values of 'height'
 >> and 'msl'?
 >
 > Since scale is 1, do you still want this?  (It would take some time to
 > get the results for Emacs 25, since I don't have the source that Debian
 > used immediately available.)  The values for Emacs 26 are
 >
 >    (gdb) print height
 >    $10 = 15
 >    (gdb) print msl
 >    $11 = 21

and in this case the scroll bar is not displayed as expected.  Since
your Emacs 25 does display the scroll bar in this case we would have
to find out why.  So it would be nice if you debugged _any_ version
that (1) does display a non-fitting scroll bar and (2) does not show
steppers because we already know that Emacs can't handle steppers.
Then we could look why in that version the msl < height check fails.

Thank you, martin

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

[Mike Kupfer]

Hi Martin, sorry about the delayed reply.

martin rudalics wrote:

> >> Then it would be interesting to break at the two if tests cited above
> >> to find out why the scroll bar is hidden for (-2 ...) in the 26 case
> >> and not in the 25 one.  Can you post the respective values of 'height'
> >> and 'msl'?
> >
> > Since scale is 1, do you still want this?  (It would take some time to
> > get the results for Emacs 25, since I don't have the source that Debian
> > used immediately available.)  The values for Emacs 26 are
> >
> >    (gdb) print height
> >    $10 = 15
> >    (gdb) print msl
> >    $11 = 21
> 
> and in this case the scroll bar is not displayed as expected.  Since
> your Emacs 25 does display the scroll bar in this case we would have
> to find out why.  So it would be nice if you debugged _any_ version
> that (1) does display a non-fitting scroll bar and (2) does not show
> steppers because we already know that Emacs can't handle steppers.
> Then we could look why in that version the msl < height check fails.

I built Emacs 25.3 from source, and it behaves the same for me as Emacs
26 (no scrollbar appears).  I don't know why the bundled emacs25 behaved
differently.  Maybe different configuration options, or Debian-specific
patches?  But at this point I have enough other things on my to-do list
that I'd rather not spend more time trying to track it down.

best regards,
mike

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

[martin rudalics]

 > I built Emacs 25.3 from source, and it behaves the same for me as Emacs
 > 26 (no scrollbar appears).  I don't know why the bundled emacs25 behaved
 > differently.  Maybe different configuration options, or Debian-specific
 > patches?  But at this point I have enough other things on my to-do list
 > that I'd rather not spend more time trying to track it down.

Thanks for all the testing.  I'm not yet sure whether to put some more
heuristics into whether and when we should suppress displaying scroll
bars on GTK builds or just document the current behavior because we'll
hardly find a solution that works reliably in all cases.

martin

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

[Mike Kupfer]

martin rudalics wrote:

> Is scaling at work?  When debugging xg_update_scrollbar_pos what is
> the value of 'scale' after doing
> 
>       int scale = xg_get_scale (f);

scale is 1.

> One more question: Can you get a GTK_SCROLL_STEP event when the slider
> is in the middle of the scroll bar such that there remains some space
> between slider and the stepper buttons.  Might be the sensitivity type
> of stepper arrows hurts us here.

No, I keep getting JUMP events.

mike

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

[Mike Kupfer]

Robert Pluim wrote:

> Iʼd test, but my theme doesnʼt have steppers.

Here's a possible way to test: if you have a mouse with multiple
buttons, right-click in the scrollbar above or below the thumb (slider).
Based on my testing, that appears to be equivalent to clicking on a
stepper button (with GTK3).

mike

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

[Robert Pluim]

Mike Kupfer <mkupfer@alum.berkeley.edu> writes:

> Robert Pluim wrote:
>
>> Iʼd test, but my theme doesnʼt have steppers.
>
> Here's a possible way to test: if you have a mouse with multiple
> buttons, right-click in the scrollbar above or below the thumb (slider).
> Based on my testing, that appears to be equivalent to clicking on a
> stepper button (with GTK3).

I get GTK_SCROLL_JUMP if I do that. I have GTK 3.18.9.

Thanks

Robert

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

[martin rudalics]

 > Here's a possible way to test: if you have a mouse with multiple
 > buttons, right-click in the scrollbar above or below the thumb (slider).
 > Based on my testing, that appears to be equivalent to clicking on a
 > stepper button (with GTK3).

The areas above and below the thumb (or slider), if they exist, serve
for jumping to the buffer position corresponding to the position
clicked at.  It's only natural that this results in a "jump" - where
calculating the new position of an object in a window relates the
position of the mouse cursor on the associated scroll bar and the size
and position of the thumb to the overall size of the object.

The arrow keys serve a completely different purpose: They support line
by line (or column by column) scrolling and are, in practice, used
only when the area reserved for the scroll bar is too small to
accommodate a thumb or the user has no mouse wheel in order to scroll
a window.  Pressing an arrow key results in a "step" - where the
calculation of the new position of an object in a window is based on
its old position plus/minus a fixed number of lines/columns or pixels.

Please keep these two concepts apart when suggesting how people should
test the behavior of their scroll bars.

Thanks, martin

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

[Andrew Kurn]

Eli wrote:

> I think we support both those who share this opinion and
> those who don't.  It sounds like you want to set
> scroll-bar-adjust-thumb-portion to nil.

Yes!!  This is the answer I've been looking for, how to
disable the feature.

Many thanks.

. . . and have you got any idea why the author used 'thumb'
in the name?  I suppose who the author is is lost in the
mists of time.

[and see below]



On Tue  3 Jul 2018 22:13 -0700, Mike Kupfer 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.

As the queen says, we never notice what other women are wearing.
Comparing emacs and gedit . . .


> 
> 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

Goodness!  Don't throw out the baby with the bath-water.  With
its faults, emacs is still emacs.

I almost said "with all its faults," but, really, I find so few
problems with emacs that even such a minor one as this one (now
understood not to be a bug at all) seems worth reporting.

Andrew

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

[Stephen Berman]

On Wed, 4 Jul 2018 00:49:22 -0700 Andrew Kurn <kurn@sfu.ca> wrote:

> Eli wrote:
>
>> I think we support both those who share this opinion and
>> those who don't.  It sounds like you want to set
>> scroll-bar-adjust-thumb-portion to nil.
>
> Yes!!  This is the answer I've been looking for, how to
> disable the feature.
>
> Many thanks.
>
> . . . and have you got any idea why the author used 'thumb'
> in the name?  

https://en.wikipedia.org/wiki/Scroll_bar:

  Although scrollbar designs differ throughout their history, they usually
  appear on one or two sides of the viewing area as long rectangular areas
  containing a bar (or thumb) that can be dragged along a trough (or
  track) to move the body of the document. [...] The “thumb” has different
  names in different environments: on the Mac OS X 10.4 it is called a
  "scroller";[3] on the Java platform it is called "thumb" or "knob";
  Microsoft's .NET documentation refers to it as "scroll box" or "scroll
  thumb"; in other environments it is called "elevator", "quint", "puck",
  "wiper" or "grip".

>               I suppose who the author is is lost in the
> mists of time.

Not with the Emacs VC fog lamp!

commit ec782c5f13fbcebe3b02106357c7daa0681a2b08
Author: Jan Djärv <jan.h.d@swipnet.se>
Date:   Fri Jan 11 05:57:45 2013 +0100

    Introduce scroll-bar-adjust-thumb-portion.
    
    * xterm.c (scroll-bar-adjust-thumb-portion): New variable to
    determine whether scroll bar thumb size should be adjusted or
    not. Use variable for MOTIF.
    
    * gtkutil.c (scroll-bar-adjust-thumb-portion): Use variable for
    GTK.

Steve Berman

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

[Noam Postavsky]

tags 32002 = fixed
close 32002 24.4
quit

Andrew Kurn <kurn@sfu.ca> writes:

> Eli wrote:
>
>> I think we support both those who share this opinion and
>> those who don't.  It sounds like you want to set
>> scroll-bar-adjust-thumb-portion to nil.
>
> Yes!!  This is the answer I've been looking for, how to
> disable the feature.

Ah, so this bug should actually be considered fixed, not wontfix.

    * Changes in Emacs 24.4

    *** New option `scroll-bar-adjust-thumb-portion'.
    Available only on X, this option allows you to control over-scrolling
    using the scroll bar (i.e., dragging the thumb down even when the end
    of the buffer is visible).

I personally have

    (define-key global-map [down] 'scroll-up-line)
    (define-key global-map [up] 'scroll-down-line)

in my .emacs, so it seems strange to have the scroll bar already all the
way to the bottom, when I'm still able to scroll farther.

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

[Mike Kupfer]

Andrew Kurn wrote:

> > 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.
[...]
> Goodness!  Don't throw out the baby with the bath-water.  With
> its faults, emacs is still emacs.

Sorry, I was unclear.  I still use Emacs, just without GTK when
possible. 

mike

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

[Andrew Kurn]

Listen, dear friends,

I was mistaken:  There's still a problem with the scroll bar
/even/ when I set scroll-bar-adjust-thumb-portion nil.

If I go to point-max, the scroll bar does indeed touch the
bottom of the track.

But, but, but if I then put the mouse on it and pull down,
the text goes off the top. (The scroll bar still covers
the whole track.)

Worse, if I mouse the bar up, nothing happens.  The text
does not reappear.

So we still got problems.

Andrew

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

[Eli Zaretskii]

> Date: Tue, 10 Jul 2018 12:16:55 -0700
> From: Andrew Kurn <kurn@sfu.ca>
> 
> But, but, but if I then put the mouse on it and pull down,
> the text goes off the top. (The scroll bar still covers
> the whole track.)

That's a feature.  You can do the same one line at a time with
"C-u 1 C-v".  Using the scroll bar invokes the same commands, so it
behaves the same.  It has nothing to do with the appearance of the
thumb.

> Worse, if I mouse the bar up, nothing happens.  The text
> does not reappear.

Really?  How do you move the thumb and to what position on the bar?

And what happens if you click on the stepper (that tiny arrow at the
top of the scroll bar)?

> So we still got problems.

Those are entirely different issues, unrelated to the size of the
thumb when all of the buffer is on display.

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

[Andrew Kurn]

On Wed 11 Jul 2018 06:02 +0300, Eli Zaretskii wrote:
> Date: Wed, 11 Jul 2018 06:02:31 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> To: Andrew Kurn <kurn@sfu.ca>
> CC: 32002@debbugs.gnu.org
> Subject: Re: bug#32002: 24.4; Scroll bar start, end not correct
> 
> > Date: Tue, 10 Jul 2018 12:16:55 -0700
> > From: Andrew Kurn <kurn@sfu.ca>
> > 
> > But, but, but if I then put the mouse on it and pull down,
> > the text goes off the top. (The scroll bar still covers
> > the whole track.)
> 
> That's a feature.

How often I have heard those words before . . .

> You can do the same one line at a time with
> "C-u 1 C-v".  Using the scroll bar invokes the same commands, so it
> behaves the same.  It has nothing to do with the appearance of the
> thumb.
> 
> > Worse, if I mouse the bar up, nothing happens.  The text
> > does not reappear.
> 
> Really?  How do you move the thumb and to what position on the bar?

With the mouse, as I said.  The thumb is now larger than the track,
so it doesn't appear to move, but it does, evident when I move it down.

> 
> And what happens if you click on the stepper (that tiny arrow at the
> top of the scroll bar)?
>
Sorry.  I'm using a theme that doesn't have them.



> Those are entirely different issues, unrelated to the size of the
> thumb when all of the buffer is on display.

This is a hint to start another bug report.

Andrew

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

[Eli Zaretskii]

> Date: Thu, 12 Jul 2018 00:11:28 -0700
> From: Andrew Kurn <kurn@sfu.ca>
> Cc: 32002@debbugs.gnu.org
> 
> > > But, but, but if I then put the mouse on it and pull down,
> > > the text goes off the top. (The scroll bar still covers
> > > the whole track.)
> > 
> > That's a feature.
> 
> How often I have heard those words before . . .

They are usually the truth.

> > You can do the same one line at a time with
> > "C-u 1 C-v".  Using the scroll bar invokes the same commands, so it
> > behaves the same.  It has nothing to do with the appearance of the
> > thumb.
> > 
> > > Worse, if I mouse the bar up, nothing happens.  The text
> > > does not reappear.
> > 
> > Really?  How do you move the thumb and to what position on the bar?
> 
> With the mouse, as I said.  The thumb is now larger than the track,
> so it doesn't appear to move, but it does, evident when I move it down.

So you are saying that no matter how many time/how long do you move
the thumb up, the text never re-appears?  Does Emacs receive
scroll-bar scroll events when you do that (you can verify that with
"C-h l")?

> > Those are entirely different issues, unrelated to the size of the
> > thumb when all of the buffer is on display.
> 
> This is a hint to start another bug report.

Yes, please.

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

[Stephen Berman]

On Thu, 12 Jul 2018 16:29:50 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> Date: Thu, 12 Jul 2018 00:11:28 -0700
>> From: Andrew Kurn <kurn@sfu.ca>
>> Cc: 32002@debbugs.gnu.org
>> 
[...]
>> > > Worse, if I mouse the bar up, nothing happens.  The text
>> > > does not reappear.
>> > 
>> > Really?  How do you move the thumb and to what position on the bar?
>> 
>> With the mouse, as I said.  The thumb is now larger than the track,
>> so it doesn't appear to move, but it does, evident when I move it down.
>
> So you are saying that no matter how many time/how long do you move
> the thumb up, the text never re-appears?  Does Emacs receive
> scroll-bar scroll events when you do that (you can verify that with
> "C-h l")?

I see this (on master built with GTK+ Version 3.22.28) when I position
the mouse pointer over the scroll bar and rotate the mouse wheel
(without clicking a mouse button): the scroll bar moves but the text
does not scroll, and view-lossage shows no scroll event.  In contrast,
when I position the mouse pointer over the text area and rotate the
mouse wheel, the text does scroll and view-lossage shows this:
 <down-mouse-5> <mouse-5> ;; mwheel-scroll
 <down-mouse-4> <mouse-4> ;; mwheel-scroll
(FWIW, with Firefox using the same GTK+ and theme, rotating the mouse
wheel over the scroll bar also scrolls the text.)

Also in contrast, when I click and hold down mouse-1 on the scroll bar
and drag it, the scroll bar moves and the text scrolls, and view-lossage
shows this:
 <mouse-1>		  ;; scroll-bar-toolkit-scroll

Steve Berman

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Andrew Kurn <kurn@sfu.ca>,  32002@debbugs.gnu.org
> Date: Thu, 12 Jul 2018 17:57:16 +0200
> 
> > So you are saying that no matter how many time/how long do you move
> > the thumb up, the text never re-appears?  Does Emacs receive
> > scroll-bar scroll events when you do that (you can verify that with
> > "C-h l")?
> 
> I see this (on master built with GTK+ Version 3.22.28) when I position
> the mouse pointer over the scroll bar and rotate the mouse wheel
> (without clicking a mouse button): the scroll bar moves but the text
> does not scroll, and view-lossage shows no scroll event.

That's expected (and is an entirely different issue): mwheel.el only
scrolls when the mouse pointer is above the text area.  You can
clearly see that in the code.

> Also in contrast, when I click and hold down mouse-1 on the scroll bar
> and drag it, the scroll bar moves and the text scrolls, and view-lossage
> shows this:
>  <mouse-1>		  ;; scroll-bar-toolkit-scroll

That's what I was asking Andrew about.

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

[Mike Kupfer]

Eli Zaretskii wrote:

> > Date: Thu, 12 Jul 2018 00:11:28 -0700
> > From: Andrew Kurn <kurn@sfu.ca>
> > Cc: 32002@debbugs.gnu.org

> > > > Worse, if I mouse the bar up, nothing happens.  The text
> > > > does not reappear.
> > > 
> > > Really?  How do you move the thumb and to what position on the bar?
> > 
> > With the mouse, as I said.  The thumb is now larger than the track,
> > so it doesn't appear to move, but it does, evident when I move it down.
> 
> So you are saying that no matter how many time/how long do you move
> the thumb up, the text never re-appears?

I can duplicate the behavior that Andrew reported, but only with

  (setq scroll-bar-adjust-thumb-portion nil)

and only if the entire buffer is displayed in the window.

With

  (setq scroll-bar-adjust-thumb-portion t)

if I

  a. drag the thumb until it touches the bottom of the track
  b. continue moving the mouse to the bottom of the thumb (holding button1)
  c. change direction and start moving the mouse up (holding button1)

the thumb doesn't move until the mouse has traveled up a bit (which
makes sense).  And the text that had scrolled off the top of the window
doesn't reappear until the thumb starts to move (which also makes
sense).

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.

> Does Emacs receive
> scroll-bar scroll events when you do that (you can verify that with
> "C-h l")?

Yes (at least for my test scenario).

best regards,
mike

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

[Eli Zaretskii]

> 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.
> 
> > Does Emacs receive
> > scroll-bar scroll events when you do that (you can verify that with
> > "C-h l")?
> 
> Yes (at least for my test scenario).

Which part of scroll-bar-toolkit-scroll gets executed when you move
the thumb up, after scrolling the entire text out of the window?  Is
it this:

	 ((eq part 'up)
	  (scroll-up -1))

or this:

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

My guess is the latter, 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.

Thanks.

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

[martin rudalics]

 > 	 ((eq part 'handle)
 > 	  (scroll-bar-drag-1 event))))
 >
 > My guess is the latter, 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.

Right, presumably.  What happens here is that in 'scroll-bar-drag-1'
we go to 'point-max' since 'portion-whole' is (1 . 1) and
'scroll-bar-scale' returns WHOLE in that case and set the start
position of that window to 'point-max'.  If, in that case, we do
nothing as in

(defun scroll-bar-drag-1 (event)
   (let* ((start-position (event-start event))
	 (window (nth 0 start-position))
	 (portion-whole (nth 2 start-position)))
     (unless (= (car portion-whole) (cdr portion-whole))
       (save-excursion
	(with-current-buffer (window-buffer window)
	  ;; Calculate position relative to the accessible part of the buffer.
	  (goto-char (+ (point-min)
			(scroll-bar-scale portion-whole
					  (- (point-max) (point-min)))))
	  (vertical-motion 0 window)
	  (set-window-start window (point)))))))

the problem is resolved.  But I'm afraid that I understand too little
about overscrolling and the portion/whole stuff to confidently
recommend such a solution.  Hopefully, you will come up with a better
one.

martin

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

[Eli Zaretskii]

> Date: Sat, 14 Jul 2018 10:01:09 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 32002@debbugs.gnu.org, kurn@sfu.ca
> 
> Right, presumably.  What happens here is that in 'scroll-bar-drag-1'
> we go to 'point-max' since 'portion-whole' is (1 . 1) and
> 'scroll-bar-scale' returns WHOLE in that case and set the start
> position of that window to 'point-max'.  If, in that case, we do
> nothing as in
> 
> (defun scroll-bar-drag-1 (event)
>    (let* ((start-position (event-start event))
> 	 (window (nth 0 start-position))
> 	 (portion-whole (nth 2 start-position)))
>      (unless (= (car portion-whole) (cdr portion-whole))
>        (save-excursion
> 	(with-current-buffer (window-buffer window)
> 	  ;; Calculate position relative to the accessible part of the buffer.
> 	  (goto-char (+ (point-min)
> 			(scroll-bar-scale portion-whole
> 					  (- (point-max) (point-min)))))
> 	  (vertical-motion 0 window)
> 	  (set-window-start window (point)))))))
> 
> the problem is resolved.  But I'm afraid that I understand too little
> about overscrolling and the portion/whole stuff to confidently
> recommend such a solution.  Hopefully, you will come up with a better
> one.

Not sure I follow: for the problem to be resolved, we need to set
window-start to some position that is not point-max.  So who does that
setting in the case in point, with your change in effect?

Or did you mean to disable scrolling-up in this case, and thus remove
the need for scrolling down?  Hmm... maybe that's the only solution to
this conundrum, but in that case I think it would be safer to add
scroll-bar-adjust-thumb-portion to your condition about portion-whole.

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

[martin rudalics]

 > Or did you mean to disable scrolling-up in this case, and thus remove
 > the need for scrolling down?

That's the idea.  The entire text stays put in the window and any
attempt to move the thumb has no effect.  Obviously, users can always
change the window start position by other means but in that case they
are on their own.

 > Hmm... maybe that's the only solution to
 > this conundrum, but in that case I think it would be safer to add
 > scroll-bar-adjust-thumb-portion to your condition about portion-whole.

There's probably more of that.  For example, I have no idea whether
the car and cdr of 'portion-whole' are always numbers.  Honestly, I
dislike the idea of changing this code myself.  My knowledge of what
scrolling should do is too limited.

martin

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

[Eli Zaretskii]

> Date: Sun, 22 Jul 2018 09:25:20 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: mkupfer@alum.berkeley.edu, 32002@debbugs.gnu.org, kurn@sfu.ca
> 
> My knowledge of what scrolling should do is too limited.

(It seems like I need to put my instructor hat on today ;-)

Let me fill you in: scrolling just needs to set the window's start
point to the desired value, all the rest is done by redisplay.  As
simple as that.

(Well, if you need to scroll more than one screenful, then you need to
worry about a few other things, like setting point such that Emacs
won't scroll back to where point is.  But this is not one of those
cases, we just scroll by one line here.)

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

[martin rudalics]

 >> My knowledge of what scrolling should do is too limited.
 >
 > (It seems like I need to put my instructor hat on today ;-)
 >
 > Let me fill you in: scrolling just needs to set the window's start
 > point to the desired value, all the rest is done by redisplay.  As
 > simple as that.

Apparently we want scrolling also to second-guess the desired value.
So things seem more complicated than that.

 > (Well, if you need to scroll more than one screenful, then you need to
 > worry about a few other things, like setting point such that Emacs
 > won't scroll back to where point is.  But this is not one of those
 > cases, we just scroll by one line here.)

Emacs scrolls by more than one line in the case at hand.

martin

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

[Eli Zaretskii]

> Date: Sun, 22 Jul 2018 09:25:20 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: mkupfer@alum.berkeley.edu, 32002@debbugs.gnu.org, kurn@sfu.ca
> 
>  > Or did you mean to disable scrolling-up in this case, and thus remove
>  > the need for scrolling down?
> 
> That's the idea.  The entire text stays put in the window and any
> attempt to move the thumb has no effect.  Obviously, users can always
> change the window start position by other means but in that case they
> are on their own.
> 
>  > Hmm... maybe that's the only solution to
>  > this conundrum, but in that case I think it would be safer to add
>  > scroll-bar-adjust-thumb-portion to your condition about portion-whole.
> 
> There's probably more of that.  For example, I have no idea whether
> the car and cdr of 'portion-whole' are always numbers.  Honestly, I
> dislike the idea of changing this code myself.  My knowledge of what
> scrolling should do is too limited.

How about putting on master a patch that does what you suggested,
conditioned on scroll-bar-adjust-thumb-portion being nil and the car
and cdr of portion-whole being both numbers?  How bad could that be,
given that this mode is evidently not used by anyone?

Thanks.

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

[martin rudalics]

 > How about putting on master a patch that does what you suggested,
 > conditioned on scroll-bar-adjust-thumb-portion being nil and the car
 > and cdr of portion-whole being both numbers?  How bad could that be,
 > given that this mode is evidently not used by anyone?

OK.  I shall do that.

martin

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

[Andrew Kurn]

On Fri 27 Jul 2018 11:23 +0200, martin rudalics wrote:
> 
> > How about putting on master a patch that does what you suggested,
> > conditioned on scroll-bar-adjust-thumb-portion being nil and the car
> > and cdr of portion-whole being both numbers?  How bad could that be,
> > given that this mode is evidently not used by anyone?
> 
> OK.  I shall do that.
> 
> martin

Um, ah, I use it, now that I know about it.

However, I admit that I don't have strong feelings about it
because I don't use the mouse much around Emacs.  It was,
after all, designed to be very key-stroke-oriented.

My interest in this bug was in having the thumb accurately
reflect the window vs. buffer  . . .

. . . and having the mode-line show the same information,
which I now see how to do, having read the latest doc.

Andrew

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

[Eli Zaretskii]

> Date: Fri, 27 Jul 2018 04:03:02 -0700
> From: Andrew Kurn <kurn@sfu.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>, mkupfer@alum.berkeley.edu,
>         32002@debbugs.gnu.org
> 
> > > How about putting on master a patch that does what you suggested,
> > > conditioned on scroll-bar-adjust-thumb-portion being nil and the car
> > > and cdr of portion-whole being both numbers?  How bad could that be,
> > > given that this mode is evidently not used by anyone?
> > 
> > OK.  I shall do that.
> > 
> > martin
> 
> Um, ah, I use it, now that I know about it.

Yes, of course.  And please also test the change that Martin will
install soon, I hope it will fix the issue with scrolling back.

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

[martin rudalics]

 > Yes, of course.  And please also test the change that Martin will
 > install soon, I hope it will fix the issue with scrolling back.

Pushed to master as commit c0809ff23d1c7080e00726bd55d1b5322391d63f.
Please have a look.

Thanks, martin

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

[Mike Kupfer]

martin rudalics wrote:

> > Yes, of course.  And please also test the change that Martin will
> > install soon, I hope it will fix the issue with scrolling back.
> 
> Pushed to master as commit c0809ff23d1c7080e00726bd55d1b5322391d63f.
> Please have a look.

I tested it briefly and found no problems.  Thanks!

mike

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

[Mike Kupfer]

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

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

[Eli Zaretskii]

> From: Mike Kupfer <mkupfer@alum.berkeley.edu>
> cc: kurn@sfu.ca, 32002@debbugs.gnu.org
> Date: Sun, 15 Jul 2018 18:47:56 -0700
> 
> 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.)

The question is what kind of correction can be applied here?  I
understand that when scroll-bar-adjust-thumb-portion is nil, the thumb
doesn't move, and so we don't even know that the thumb was dragged
upwards, is that true?  If so, how can we know that the user meant
scrolling up?