Re: Top line clipping destroys Gnus
At 11:16 PM 8/31/99 +0200, Hrvoje Niksic wrote:
Another newspaper-headline-like subject. To see this, view an article
that is longer than your screen and that contains an x-face. Then
press RET to scroll down by one line (I often read that way.) After
the first RET, the scrolling is correct (wow, the top line actually
clipped!) However, the second time Gnus is completely confused, and
jumps by a whole page.
Now, this may very well be a Gnus bug, but even in that case the fact
that Gnus got screwed with the change may prove indicative.
Andy, could you please describe the exact behavioural change that your
top-line-clipping patch induces? I've seen the patch, but I don't
remember seeing a description. Not being a redisplay expert, a
description would help *a lot*.
I've changed the redisplay of display lines so that they can be clipped at
the top as well as at the bottom. I have also added a top_yoffset variable
to window.h which indicates how much the display lines should be offset
(this is 0 for normal scrolling). I have then modified window_scroll() so
that if you are trying to scroll an increment < (height of the top line) /
height of the default face then this offset will get incremented by an
amount == height of the default face and point is left alone. Thus for
large lines you will gradually clip until the visible portion is <= height
of the default face at which point the whole line is scrolled.
If you scroll up redisplay cannot tell the height of the line it is about
to put at the top so I am afraid that the whole line is shown, even if it
is very tall. However, if you scroll down partially clipping a line and
then scroll back up again things work ok. I guess gnus might be assuming
that if point doesn't move then its time to move on to the next article ?
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd