>> 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.
Agreed. >> 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. 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. >> 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. Agreed (see comments in windmove.el, one of the two packages that use this function; the other being avoid.el, and also the window-buffer-height function in window.el). 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. I.e. compute-motion could be made obsolete, in my opinion. 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). > 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. 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? Stefan --- orig/lisp/window.el +++ mod/lisp/window.el @@ -521,20 +521,12 @@ (defun window-buffer-height (window) "Return the height (in screen lines) of the buffer that WINDOW is displaying." - (save-excursion - (set-buffer (window-buffer window)) - (goto-char (point-min)) - (let ((ignore-final-newline - ;; If buffer ends with a newline, ignore it when counting height - ;; unless point is after it. - (and (not (eobp)) (eq ?\n (char-after (1- (point-max))))))) - (+ 1 (nth 2 (compute-motion (point-min) - '(0 . 0) - (- (point-max) (if ignore-final-newline 1 0)) - (cons 0 100000000) - nil - nil - window)))))) + (with-current-buffer (window-buffer window) + (count-screen-lines (point-min) (point-max) + ;; If buffer ends with a newline, ignore it when + ;; counting height unless point is after it. + (or (eobp) (not (eq ?\n (char-before (point-max))))) + window))) (defun count-screen-lines (&optional beg end count-final-newline window) "Return the number of screen lines in the region. _______________________________________________ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug