> 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 can be done by computing the vertical position of point at the
start of the line, and at the start of the following line. So
compute-motion or something similar is exactly what would be needed.
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).
This is more or less the same thing as using compute-motion, which
would call the display code internally anyway, but with a different
interface. (That interface should be a new function, not sit-for.
It could be called update-display-state.)
This might be more convenient than compute-motion, for things it can
do. However, it might be hard to use for certain things, such as
when it isn't clear where to start the "display", or for motion extending
further than one screenful, or when you don't know whether it fits in
one screenful.
_______________________________________________
Emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
