scrollbar (once more)

scrollbar (once more)

[Luc Teirlinck]

Just a strange little detail about the native scrollbar.  (I did not
check how other scrollbars behave in the same situation.)

Do C-h n, put the region around:

GNU Emacs NEWS -- history of user-visible changes.  2001-03-15
Copyright (C) 1999, 2000, 2001, 2002, 2003 Free Software Foundation,
Inc.  See the end for copying conditions.

Make sure that the trailing newline is included.

C-x n n.

The thumb now covers the entire scrollbar.  No problem with me.

Let us start with everybody's favorite activity: overscrolling.

Put the second line at the top, say with M-0 C-l, or by dragging the
scrollbar.  The thumb now occupies a little bit more than half of the
scrollbar, because that is the percentage of accessible characters
still visible.  Wonderful.

Third line to the top.  Thumb shrinks to expected size.

Final step of overscrolling: last line to the top.

The thumb now covers nearly the entire length of the scrollbar,
because the inaccessible portion all of a sudden starts "counting".

Does this make sense?

You can see a similar effect by doing C-h i m cl and overscrolling all
the way to the bottom.  Actually, this is the way I noticed the
problem, assuming it is one.  (In Info, it is confusing.)

I am afraid that I am starting to suffer from Obsessive Scrolling Disorder.

Sincerely,

Luc.

Re: scrollbar (once more)

[Robert J. Chassell]

I am able to reproduce this oddity using *today's* CVS snapshot, but
earlier, I could not reproduce it using yesterday's CVS snapshot.  It
is possible that with yesterday's CVS snapshot, I did not scroll down
far enough to see the effect; but I don't know.

In any event, this is a reproduceable oddity.

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

   Just a strange little detail about the native scrollbar.  ....

   Do C-h n, put the region around:

   GNU Emacs NEWS -- history of user-visible changes.  2001-03-15
   Copyright (C) 1999, 2000, 2001, 2002, 2003 Free Software Foundation,
   Inc.  See the end for copying conditions.

   Make sure that the trailing newline is included.

   C-x n n.

   The thumb now covers the entire scrollbar.  No problem with me.

   ... 

   Third line to the top.  Thumb shrinks to expected size.

   Final step of overscrolling: last line to the top.

   The thumb now covers nearly the entire length of the scrollbar,
   because the inaccessible portion all of a sudden starts "counting".

   Does this make sense?

Reproduced using:

Today's CVS snapshot, Thu, 2003 Apr  3  12:40 UTC
GNU Emacs 21.3.50.271 (i686-pc-linux-gnu, X toolkit)
LUCID tool kit
started with

     /usr/local/bin/emacs -q --no-site-file --eval '(blink-cursor-mode 0)'

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: scrollbar (once more)

[Richard Stallman]

    The thumb now covers nearly the entire length of the scrollbar,
    because the inaccessible portion all of a sudden starts "counting".

I'd call it a bug.  Could you try to figure out what causes it?

Re: scrollbar (once more)

[Luc Teirlinck]

Richard Stallman wrote:

       The thumb now covers nearly the entire length of the scrollbar,
       because the inaccessible portion all of a sudden starts "counting".

   I'd call it a bug.  Could you try to figure out what causes it?

Somehow, with the narrowed buffer completely out of view above the
window and point just after the final newline, the computation of the
thumb length seems to count the entire inaccessible portion after point
as "present" in the window.  Apparently, (- (buffer-size) (point))
characters get counted as present in the window.

Does the thumb size of the (native) scrollbar get adjusted in the Lisp
or in the C code?  At first view, I have the impression that it is in
the C code.  (Although I am not sure.)  While I know C, I am not
really familiar with Emacs' C code and while I intend to sooner or
later familiarize myself with it, I do not have the time to start
studying it at present.

Sincerely,

Luc.

Re: scrollbar (once more)

[Stefan Monnier]

> Richard Stallman wrote:
> 
>        The thumb now covers nearly the entire length of the scrollbar,
>        because the inaccessible portion all of a sudden starts "counting".
> 
>    I'd call it a bug.  Could you try to figure out what causes it?
> 
> Somehow, with the narrowed buffer completely out of view above the
> window and point just after the final newline, the computation of the
> thumb length seems to count the entire inaccessible portion after point
> as "present" in the window.  Apparently, (- (buffer-size) (point))
> characters get counted as present in the window.
> 
> Does the thumb size of the (native) scrollbar get adjusted in the Lisp
> or in the C code?  At first view, I have the impression that it is in
> the C code.  (Although I am not sure.)  While I know C, I am not
> really familiar with Emacs' C code and while I intend to sooner or
> later familiarize myself with it, I do not have the time to start
> studying it at present.

It's in set_vertical_scroll_bar (which I just created a few days ago
by extracting the code out of redisplay_window).


	Stefan

Re: scrollbar (once more)

[Richard Stallman]

    > Somehow, with the narrowed buffer completely out of view above the
    > window and point just after the final newline, the computation of the
    > thumb length seems to count the entire inaccessible portion after point
    > as "present" in the window.  Apparently, (- (buffer-size) (point))
    > characters get counted as present in the window.

    It's in set_vertical_scroll_bar (which I just created a few days ago
    by extracting the code out of redisplay_window).

Can you fix this bug?

Re: scrollbar (once more)

[Stefan Monnier]

>     > Somehow, with the narrowed buffer completely out of view above the
>     > window and point just after the final newline, the computation of the
>     > thumb length seems to count the entire inaccessible portion after point
>     > as "present" in the window.  Apparently, (- (buffer-size) (point))
>     > characters get counted as present in the window.
> 
>     It's in set_vertical_scroll_bar (which I just created a few days ago
>     by extracting the code out of redisplay_window).
> 
> Can you fix this bug?

No.  I don't know what might be wrong there and/or if the bug
is even in there.

I haven't actually touched that code other than moving it out
of redisplay_window so that I could call it after an end_scoll event.


	Stefan

Re: scrollbar (once more)

[Luc Teirlinck]

Stefan Monnier wrote:

   I haven't actually touched that code other than moving it out
   of redisplay_window so that I could call it after an end_scoll event.

I can confirm that the bug was not caused by moving
set_vertical_scroll_bar out of redisplay_window.  The bug already
occurs in 21.1.90 (as well as in 21.2.90).  It did not occur in 20.7.
If I would have to make a guess, I would guess that tha bug is in
redisplay, whether in redisplay_window, or in some other function
connected with redisplay.  (window-end nil t) returns the correct
value (end of the accessible portion), whereas (window-end) returns
one more than (buffer-size).

Sincerely,

Luc.

Re: scrollbar (once more)

[Luc Teirlinck]

Line 11235 of xdisp.c:

 end = BUF_Z (buf) - XFASTINT (w->window_end_pos) - BUF_BEGV (buf);

(in function set_vertical_scroll_bar)

Lines 978-981 of window.c:

  else
    XSETINT (value, BUF_Z (XBUFFER (buf)) - XFASTINT (w->window_end_pos));

  return value;

(in function window-end)

Both set_vertical_scroll_bar and (window-end) do the wrong thing,
because they both use the above expression, in which something must be
wrong.  My best guess is that redisplay does not get w->window_end_pos
right.  I do not know enough about either the Emacs C code or
redisplay to go beyond this.  I definitely do not have the time to
start studying that code at present.  Is anybody familiar with the new
redisplay mechanism (except for Gerd who wrote it)?  (window-end nil t) 
gets things right.

Sincerely,

Luc.

Re: scrollbar (once more)

[Richard Stallman]

       Third line to the top.  Thumb shrinks to expected size.

       Final step of overscrolling: last line to the top.

       The thumb now covers nearly the entire length of the scrollbar,
       because the inaccessible portion all of a sudden starts "counting".


    Both set_vertical_scroll_bar and (window-end) do the wrong thing,
    because they both use the above expression, in which something must be

I think I have fixed it.  Does this make it work?

*** xdisp.c.~1.825.~	Sun Mar 30 14:24:03 2003
--- xdisp.c	Mon Apr 14 06:29:29 2003
***************
*** 12006,12013 ****
      }
    else
      {
!       w->window_end_bytepos = 0;
!       w->window_end_pos = w->window_end_vpos = make_number (0);
      }
  
    /* But that is not valid info until redisplay finishes.  */
--- 12006,12014 ----
      }
    else
      {
!       w->window_end_bytepos = Z_BYTE - ZV_BYTE;
!       w->window_end_pos = make_number (Z - ZV);
!       w->window_end_vpos = make_number (0);
      }
  
    /* But that is not valid info until redisplay finishes.  */
***************
*** 12220,12227 ****
        else
  	{
  	  /* This window must be completely empty.  */
! 	  w->window_end_bytepos = 0;
! 	  w->window_end_pos = w->window_end_vpos = make_number (0);
  	}
        w->window_end_valid = Qnil;
  
--- 12221,12229 ----
        else
  	{
  	  /* This window must be completely empty.  */
! 	  w->window_end_bytepos = Z_BYTE - ZV_BYTE;
! 	  w->window_end_pos = make_number (Z - ZV);
! 	  w->window_end_vpos = make_number (0);
  	}
        w->window_end_valid = Qnil;

Re: scrollbar (once more)

[Luc Teirlinck]

Richard Stallman wrote:

	  Third line to the top.  Thumb shrinks to expected size.

	  Final step of overscrolling: last line to the top.

	  The thumb now covers nearly the entire length of the scrollbar,
	  because the inaccessible portion all of a sudden starts "counting".


       Both set_vertical_scroll_bar and (window-end) do the wrong thing,
       because they both use the above expression, in which something must be

   I think I have fixed it.  Does this make it work?

Yes, it does.

Sincerely,

Luc.

Re: scrollbar (once more)

[Richard Stallman]

       I'd call it a bug.  Could you try to figure out what causes it?

    Somehow, with the narrowed buffer completely out of view above the
    window and point just after the final newline, the computation of the
    thumb length seems to count the entire inaccessible portion after point
    as "present" in the window.

That is what happens, but what we need to know is why.

I don't know that code myself, and I am failing to keep up with my mail
this week, so I hope someone can figure out the cause of the problem.

Re: scrollbar (once more)

[Luc Teirlinck]

Richard Stallman wrote:

	  I'd call it a bug.  Could you try to figure out what causes it?

       Somehow, with the narrowed buffer completely out of view above the
       window and point just after the final newline, the computation of the
       thumb length seems to count the entire inaccessible portion after point
       as "present" in the window.

   That is what happens, but what we need to know is why.

   I don't know that code myself, and I am failing to keep up with my mail
   this week, so I hope someone can figure out the cause of the problem.

I figured out that the bug is in window-end.  I will soon file an amended
bug report pointing out the bug in window-end.

Sincerely,

Luc.

bug in window-end

[Luc Teirlinck]

The following bug in window-end completely explains the problem with
the native scrollbar I pointed out before.

I will just keep using the same example I used before.

C-h n.

Region around:

GNU Emacs NEWS -- history of user-visible changes.  2001-03-15
Copyright (C) 1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc.
See the end for copying conditions.

Make sure the final newline is included.

C-x n n

M-: (window-end) will correctly give 174 in all kinds of situations,
except:

move to behind the final newline and do

M-0 C-l

Now M-: (window-end) returns 458732, one more than

M-: (buffer-size), 458731

M-: (window-start) in this situation returns 174, the same thing
window-end should be returning (or so I believe).

Some apparently suspicious code in window-end:

      /* In case W->start is out of the range, use something
         reasonable.  This situation occurred when loading a file with
         `-l' containing a call to `rmail' with subsequent other
         commands.  At the end, W->start happened to be BEG, while
         rmail had already narrowed the buffer.  */
      if (XMARKER (w->start)->charpos < BEGV)
      SET_TEXT_POS (startp, BEGV, BEGV_BYTE);
      else if (XMARKER (w->start)->charpos > ZV)
      SET_TEXT_POS (startp, ZV, ZV_BYTE);
      else
      SET_TEXT_POS_FROM_MARKER (startp, w->start);

I do not feel familiar enough with the Emacs C code to really mess
with this.  I hope the above helps anyway.

Sincerely,

Luc.

Re: bug in window-end

[Luc Teirlinck]

>From my previous message:

   The following bug in window-end completely explains the problem with
   the native scrollbar I pointed out before.

That may have been a premature conclusion.  Both bugs may have a
common cause (say in redisplay or whatever).

   move to behind the final newline and do

   M-0 C-l

   Now M-: (window-end) returns 458732,

But M-: (window-end nil t) returns 174, the correct value, hence it
would seem that there is nothing wrong with the code I labeled
"suspicious" in my previous message.  I quite simply do not know the C
code well enough and hence I will refrain from making further
conjectures, which would probably be all wrong anyway.

Sincerely,

Luc.