On Mon, 22 Oct 2001, Eric Eide said:
I don't believe that I've seen this problem. If you can
provide a recipe,
maybe I can reproduce the behavior and fix whatever bug there might be.
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