This is an unfix, because fixing this reveals a bunch of glitches. First of all, I want to point that the change which introduced window-pixel-scroll-increment was *not* a bug, it revealed a bug too. Without this change, the same effects show if the default face font is much shorter than the font used for current display lines. Second of all, printing will require this type of scroll, or at least an ability to position window in such a way that line is clipped. (If a display line is taller than N, it can be split between pages. Second page starts at that line, with its top clipped). So I want to keep this feature - it just has to be finished. Set window-pixel-scroll-increment to 1. When scrolling down using scrollbar arrow, display moves smoothly, jumping over line descents. This jumping is perhaps correct, so window display cannot start in a middle of inter-line spacing. When scrolling up, scroll goes smoothly only before the top of the partially obscured top line hits the window top. Since then, scrolling switches back to per-line scroll. I added code which fixes it, but it loses. It is #if0'ed now, and I would be grateful if someone can suggest me how to fix it. This is a problem #1. The problem #2 manifests itself when a top line is clipped. It remains clipped when a) buffers are switched in a window, b) when window is scrolled by way of regenerating it. I tried to find all places in regenerate where it should be reset, but it appears too deep in regenerate when the decision should be made to reset top clipping, so effectively regenerate should be restarted. As a solution, I want to introduce a window flag which tells regenerate *not* to reset clipping even if buffer has moved in the window vertically. If not set, regenrate_window will reset clipping. I do not feel this being an elegant solution though: regenerate is idempotent, so that it can be applied to a window many times with the same result; it stops being such when it depends on a flag which it resets by itself. I'd appreciate comments on that. Big K 2000-01-18 Kirill 'Big K' Katsnelson <kkm(a)dtmx.com&gt; * window.c (window_scroll): Fixed a typo which caused Vwindow_pixel_scroll_increment to be disregarded. Added bits of #if0'ed code. It should be fixed and uncommented. Index: window.c =================================================================== RCS file: /var/cvsroot/xemacs/src/window.c,v retrieving revision 1.1.1.3 diff --unified=4 -r1.1.1.3 window.c --- src/window.c 2000/01/18 23:27:52 1.1.1.3 +++ src/window.c 2000/01/19 03:38:35 ＠＠ -4050,9 +4050,9 ＠＠ dla = window_display_lines (w, CURRENT_DISP); if (INTP (Vwindow_pixel_scroll_increment)) fheight = XINT (Vwindow_pixel_scroll_increment); - else if (!NILP (Vwindow_pixel_scroll_increment)); + else if (!NILP (Vwindow_pixel_scroll_increment)) default_face_height_and_width (window, &fheight, &fwidth); if (Dynarr_length (dla) >= 1) modeline = Dynarr_atp (dla, 0)->modeline; ＠＠ -4157,8 +4157,25 ＠＠ w->buffer); w->force_start = 1; w->start_at_line_beg = beginning_of_line_p (b, startp); MARK_WINDOWS_CHANGED (w); + +#if 0 + /* #### Scroll back by less than a line. This code loses + when a line being exposed at the top of the window has + different height than the current one. Display lines + array is not regenerated so far, so I see no way to + determine the height of the line which begins at + STARTP. Anyone? -- kkm */ + + if (!NILP (Vwindow_pixel_scroll_increment) + && Dynarr_length (dla) >= (1 + modeline) + && dl->ascent - dl->top_clip + fheight * value > 0) + { + WINDOW_TEXT_TOP_CLIP (w) = (dl->ascent - dl->top_clip + + fheight * value); + } +#endif if (!point_would_be_visible (w, startp, XINT (point))) { Bufpos new_point;