Richard Stallman <[EMAIL PROTECTED]> writes: > To make reliable judgement about the display state, line-move must > call sit-for which does redisplay. > > That is a really bad problem.
IMO, it is not too bad -- line-move is primarily (solely?) for interactive use, so redisplay will happen after the command anyway. > We need to redesign this. > In the past, functions such as compute-motion did the job. > But they have not yet been upgraded to handle computations > involving variabled width fonts, images, etc. The problem is not motion as such, but to know whether the resulting position of point is on a partially visible line, so vscroll may be needed. > > That has been in etc/TODO for many years, but nobody has done > it. We need this! IMO, compute-motion is too cumbersome to use. A much better approach (IMO) would be to be able to use sit-for to update the internal state, but without actually updating the display (sort of generating the desired matrix without updating the current matrix; then code could just assume the display is up-to-date already). On the surface, this may be rather tricky as the desired matrix is only built temporarily, and all external code references the current matrix. But what about this (simple) idea: Provide a function update-display-state which does _everything_ in redisplay, except doing Xflush (or similar for other platforms). Then the user display is not updated visually with a possible premature result. The Xflush will be performed on next normal redisplay or by calling sit-for etc. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk _______________________________________________ Emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
