Hrvoje Niksic <hniksic(a)srce.hr&gt; writes: 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. i.e. 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. 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 code. Jan 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?