Hrvoje Niksic <hniksic(a)srce.hr&gt; writes: Was an attempt at fixing Gnus made? Or at least an attempt at really finding out what is wrong.[1] Jan P.S. If the functionality was implemented without a way to switch it of from lisp land that would be bad too. Footnotes: [1] For instance gnus-article-next-page seems weird but OK. I am trying to find the original discussion again... Aha here it is.. Hmm: Andy's patch was never on xemacs-patces? Hmm 2: You'r problem was with RET, let's have another look I don't use XEmacs 21.2 here normally .... ... minutes pass while configure and make do their job .... Firing up gnus... Switching to the ding list to get a high xface ratio.... huh? aahhh I don't have them displayed by default. I can now reproduce your problem. Ok Let's put edebug on gnus-article-next-page 5 minutes of play... EUREKA! I think I know what the problem is now... pos-visible-in-window-p fails to take into account the top line clip.... I think all functions that use VERTICAL_CLIP should be revised to takes this into account. This patch fixes your scrolling problem for me Index: redisplay.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay.c,v retrieving revision 1.55.2.17 diff -u -u -r1.55.2.17 redisplay.c --- redisplay.c 1999/09/28 00:43:01 1.55.2.17 +++ redisplay.c 1999/10/23 20:12:45 ＠＠ -7456,7 +7456,7 ＠＠ point_would_be_visible (struct window *w, Bufpos startp, Bufpos point) { struct buffer *b = XBUFFER (w->buffer); - int pixpos = 0; + int pixpos = -WINDOW_TEXT_TOP_CLIP(w); int bottom = WINDOW_TEXT_HEIGHT (w); int start_elt; However the top clipping stuff is still very experimental, see what happens after a scrolling few lines It is also not obvious to me, if, how, why and when the clip is reset back to 0. Andy?