Hrvoje Niksic <hniksic(a)srce.hr> writes:
Because it covers the whole window, including the clipped line.
the GUARANTEE value, I need to apply (forward-line) twice to the value
Aha.. I understand now I was not reading correctly. Then the GUARANTEE
is also wrong, IMHO it should return the position of the last visible
char including that one on the clipped line.
This is the last line you can reach with the cursor.A
This is the clipped line, which is infact also brok\B
Cen because it is too long.
DThis is is the first line in the buffer that is not visible.
so (window-end) gives D, (window-end nil t) gives A, and I think the
correct answer is B.
The problem with all this of course that some of these functions are
intentionally broken, for instance to accommodate old FSF code that
makes assumptions about being able to move the cursor up to that point.
I have no idea if it is feasible to use the line-start cache for the
purposes of window-start. It may be hard or impossible.
It is the right thing, it is feasible, it laid out for such uses (this
is why there are actually 3 line start caches).
It however also hard, because the line start cache stuff is hard in
general. Personally I think this the most dense part of the XEmacs C
P.S. Another redisplay problem. Open a large frame. Start
C-u 6 M-x hanoi RET. Now resize the frame so that the towers _just_
fit. I see enormous redisplay speedup in that case. Why do the
additional empty lines in the large display matter that much?