Stefan Monnier <[EMAIL PROTECTED]> writes: > To make scrolling (even of images or lines of widely different height) > reliable, compute-motion would need to pay attention to every display > element and parameter, including things like frame-local face properties. > > So either it re-implements the redisplay or it reuses the redisplay. > > I.e. the current code of line-move reuses the result of redisplay, which > seems to be the best solution.
Agree. > For both avoid.el and windmove.el, compute-motion is used to get the X/Y > coordinate of point. I.e. posn-at-point would be a better choice now. > > As for window-buffer-height, the patch below simplifies it by using > count-screen-lines (which uses vertical-motion) rather than compute-motion. Seems good to me. > I.e. compute-motion could be made obsolete, in my opinion. Agree!! > OTOH vertical-motion seems to be used more frequently and its behavior is > similar to compute-motion (it can be used for a buffer that's not currently > displayed), so maybe there is indeed a need to compute hypothetical display > behavior (i.e. display behavior of something that is not displayed). True -- I didn't think about that aspect. Also, vertical-motion does pay attention to variable pitch/height, so that's another reason to use it in favour of compute-motion. > But maybe it's important to be able to compute the matrix without *ever* > displaying it. E.g. in fit-window-to-buffer, count-screen-lines is used to > decide how to resize the window. > In the case where the matrix will be displayed sooner or later, I don't > think it makes much sense to delay the Xflush. What's the benefit? I was thinking about the situation where the sit-for in line-move results in a situation where we would adjust the vscroll, and thus update the display once more. I haven't noticed this myself, but I could envision that may cause flickering. -- 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
