On 13 Oct 2001, Stephen J. Turnbull stated: scroll-in-place is supposed to do exactly this, but it doesn't always work; sometimes you just get a {beginning,end}-of-buffer error. I vote for fixing scroll-in-place, myself. -- `A truly dreadful film destined to be a cult classic for masochists.' --- Chris Priest on _A.I._.

On Mon, 22 Oct 2001, Eric Eide said: I dug into this at last (only six months after you asked) and found bigger problems. I think big chunks of scroll-in-place's design are probably wrong. s-i-p assumes that the window's height in lines is not changed by moving around in the buffer; in the presence of variable-height lines, this assumption is untrue. This leads to scrolling that skips big chunks of text when scroll-in-place is on. In fact, in the presence of variable-height lines, you might well have *less* than one line on the screen (it's a big image), in which case scroll-in-place stops you from seeing anything but the top of the image at all. Tha algorithm needs, as far as I can see, to distinguish between scrolling with a LINES argument (in which case it does, of course, want to scroll by some number of lines) and scrolling without one (in which case it wants to scroll by an entire screen, however big that is, *and it must recompute that on every call*.) So, what we should do instead, perhaps: If we are scrolling by entire screens, we remember that fact. On each call, we check if `window-text-area-height' != `window-displayed-height'. If this is true, then we have non-default-height lines, and we have to be careful. If the `window-displayed-height' is 0, we're stuffed; we just call scroll-up/down and let them take the rap. If it's the >0 but <`window-text-area-height', then we scroll that many lines, but *don't remember that count* (intentionally). We have the problem when scrolling up (or, as the Emacsen call it, `down') that we don't know how many lines are on the screen above us until we move there. So We start by assuming that we can scroll back `window-text-area-height' lines by calling `original-scroll-down', take note of the last visible line via `window-displayed-height', and if it's not right we adjust it, repeating until correct. Then we reposition the cursor appropriately. Gagh, this is horrible :( The XEmacs core has special-case code (in window.c:window_scroll()) to handle all this mess, but I can't see a way for it to be called from Lisp. It might be simpler if scroll-in-place just called scroll-down/scroll-up and then tried to fix up what they return, because I don't think they can be reliably reimplemented in Lisp at all... (btw, also, we should use `window-text-area-height', not `window-height', at all times; as it is the more gutters you've got, the more wrong scroll-in-place gets.) I'll try to fix this myself, but I'm really busy right now; if you get to it before I do, please fix it! ;) as it is w3m, w3, and other things relying on variable-height lines are rather hard to use when scroll-in-place is loaded. -- `Frankly I wonder whether you are not writing your posts from underneath a bridge.' --- Jason Clifford, to a particularly dense troll

On Fri, 22 Mar 2002, Eric Eide spake: A week is nothing ;) Great! Look at w3m or preview-latex or something like that with lots of big images and say it's right ;) --- sure, *when you wrote it* it was entirely correct. But reality changes, and torpedoes the best of us :( It was that long ago? [checks] Sheesh. I misread it as 1998... I need a new pair of glasses, or saving that a new brain. You're to be commended for writing code that deals in such a delicate area and held up so well, then :) OK. If I get annoyed enough by it I'll send some patches your way. (The thing I'm working on right now, preview-latex, leads to *lots* of variable-height lines.) -- `Oh, I seeeee, good light; bad light. Presumably the bad light is different -- perhaps it's a sawtooth waveform, and the pointy bits scratch your eyes?' --- John Ineson to a `monitors emit radiation, all radiation is bad, therefore monitors are bad' tub-thumper