unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* scrollbar (once more)
@ 2003-04-03  2:35 Luc Teirlinck
  2003-04-03 13:15 ` Robert J. Chassell
  2003-04-03 22:52 ` Richard Stallman
  0 siblings, 2 replies; 15+ messages in thread
From: Luc Teirlinck @ 2003-04-03  2:35 UTC (permalink / raw)


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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: scrollbar (once more)
  2003-04-03  2:35 scrollbar (once more) Luc Teirlinck
@ 2003-04-03 13:15 ` Robert J. Chassell
  2003-04-03 22:52 ` Richard Stallman
  1 sibling, 0 replies; 15+ messages in thread
From: Robert J. Chassell @ 2003-04-03 13:15 UTC (permalink / raw)
  Cc: Luc Teirlinck

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: scrollbar (once more)
  2003-04-03  2:35 scrollbar (once more) Luc Teirlinck
  2003-04-03 13:15 ` Robert J. Chassell
@ 2003-04-03 22:52 ` Richard Stallman
  2003-04-04  4:41   ` Luc Teirlinck
  1 sibling, 1 reply; 15+ messages in thread
From: Richard Stallman @ 2003-04-03 22:52 UTC (permalink / raw)
  Cc: emacs-devel

    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?

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: scrollbar (once more)
  2003-04-03 22:52 ` Richard Stallman
@ 2003-04-04  4:41   ` Luc Teirlinck
  2003-04-04 14:51     ` Stefan Monnier
  2003-04-04 22:24     ` Richard Stallman
  0 siblings, 2 replies; 15+ messages in thread
From: Luc Teirlinck @ 2003-04-04  4:41 UTC (permalink / raw)
  Cc: emacs-devel

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: scrollbar (once more)
  2003-04-04  4:41   ` Luc Teirlinck
@ 2003-04-04 14:51     ` Stefan Monnier
  2003-04-05  8:12       ` Richard Stallman
  2003-04-04 22:24     ` Richard Stallman
  1 sibling, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2003-04-04 14:51 UTC (permalink / raw)
  Cc: emacs-devel

> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: scrollbar (once more)
  2003-04-04  4:41   ` Luc Teirlinck
  2003-04-04 14:51     ` Stefan Monnier
@ 2003-04-04 22:24     ` Richard Stallman
  2003-04-04 23:11       ` Luc Teirlinck
  1 sibling, 1 reply; 15+ messages in thread
From: Richard Stallman @ 2003-04-04 22:24 UTC (permalink / raw)
  Cc: emacs-devel

       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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: scrollbar (once more)
  2003-04-04 22:24     ` Richard Stallman
@ 2003-04-04 23:11       ` Luc Teirlinck
  2003-04-04 23:37         ` bug in window-end Luc Teirlinck
  0 siblings, 1 reply; 15+ messages in thread
From: Luc Teirlinck @ 2003-04-04 23:11 UTC (permalink / raw)
  Cc: emacs-devel

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug in window-end
  2003-04-04 23:11       ` Luc Teirlinck
@ 2003-04-04 23:37         ` Luc Teirlinck
  2003-04-05  4:41           ` Luc Teirlinck
  0 siblings, 1 reply; 15+ messages in thread
From: Luc Teirlinck @ 2003-04-04 23:37 UTC (permalink / raw)
  Cc: emacs-devel

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: bug in window-end
  2003-04-04 23:37         ` bug in window-end Luc Teirlinck
@ 2003-04-05  4:41           ` Luc Teirlinck
  0 siblings, 0 replies; 15+ messages in thread
From: Luc Teirlinck @ 2003-04-05  4:41 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: scrollbar (once more)
  2003-04-04 14:51     ` Stefan Monnier
@ 2003-04-05  8:12       ` Richard Stallman
  2003-04-06 21:05         ` Stefan Monnier
  0 siblings, 1 reply; 15+ messages in thread
From: Richard Stallman @ 2003-04-05  8:12 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: scrollbar (once more)
  2003-04-05  8:12       ` Richard Stallman
@ 2003-04-06 21:05         ` Stefan Monnier
  2003-04-06 21:37           ` Luc Teirlinck
  0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2003-04-06 21:05 UTC (permalink / raw)
  Cc: 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: scrollbar (once more)
  2003-04-06 21:05         ` Stefan Monnier
@ 2003-04-06 21:37           ` Luc Teirlinck
  2003-04-06 22:51             ` Luc Teirlinck
  0 siblings, 1 reply; 15+ messages in thread
From: Luc Teirlinck @ 2003-04-06 21:37 UTC (permalink / raw)
  Cc: monnier+gnu/emacs

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: scrollbar (once more)
  2003-04-06 21:37           ` Luc Teirlinck
@ 2003-04-06 22:51             ` Luc Teirlinck
  2003-04-15  2:06               ` Richard Stallman
  0 siblings, 1 reply; 15+ messages in thread
From: Luc Teirlinck @ 2003-04-06 22:51 UTC (permalink / raw)
  Cc: monnier+gnu/emacs

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: scrollbar (once more)
  2003-04-06 22:51             ` Luc Teirlinck
@ 2003-04-15  2:06               ` Richard Stallman
  2003-04-15  2:49                 ` Luc Teirlinck
  0 siblings, 1 reply; 15+ messages in thread
From: Richard Stallman @ 2003-04-15  2:06 UTC (permalink / raw)
  Cc: monnier+gnu/emacs

       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;

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: scrollbar (once more)
  2003-04-15  2:06               ` Richard Stallman
@ 2003-04-15  2:49                 ` Luc Teirlinck
  0 siblings, 0 replies; 15+ messages in thread
From: Luc Teirlinck @ 2003-04-15  2:49 UTC (permalink / raw)
  Cc: monnier+gnu/emacs

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2003-04-15  2:49 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-04-03  2:35 scrollbar (once more) Luc Teirlinck
2003-04-03 13:15 ` Robert J. Chassell
2003-04-03 22:52 ` Richard Stallman
2003-04-04  4:41   ` Luc Teirlinck
2003-04-04 14:51     ` Stefan Monnier
2003-04-05  8:12       ` Richard Stallman
2003-04-06 21:05         ` Stefan Monnier
2003-04-06 21:37           ` Luc Teirlinck
2003-04-06 22:51             ` Luc Teirlinck
2003-04-15  2:06               ` Richard Stallman
2003-04-15  2:49                 ` Luc Teirlinck
2003-04-04 22:24     ` Richard Stallman
2003-04-04 23:11       ` Luc Teirlinck
2003-04-04 23:37         ` bug in window-end Luc Teirlinck
2003-04-05  4:41           ` Luc Teirlinck

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).