bug#16431: 24.3.50; `follow-adjust-windows' sometimes fails (patch included)

[Anders Lindgren]

Hi!

 

> One thing still seems to be problematic -- `follow-adjust-window' only work
> properly when `win' is *selected*.

Indeed, I was tempted to add a (cl-assert (eq win (selected-window))) or
to remove the `win' argument altogether.  I didn't do it mostly because
I remembered that we're in feature freeze.

Hmm, but I would qualify that as a bug fix. Besides, you have already changed the signature of `follow-adjust-window', so in some way we are already thumbing on the rules somewhat.

> In other words, that I would like to see is the following:

>         (let ((source-pos ....))
>           (with-current-buffer (window-buffer win)
>             (goto-char source-pos)
>             (follow-adjust-window win)))

I don't understand why you'd want to compute source-pos while outside of
(window-buffer win).

Oh, I just wanted to show that it came from "the outside" -- it's not really important for the example. Think of this as the location of the "grep hit" or the location which "compile" should present as containing an error. (In my application, it's the location of the current search result of a font-lock rule.)

Anyway, the effect that I'm after is that I want the user to walk through a number of locations in a file (again, think of grep hits). As long as the location is visible in one of the side-by-side windows I simply present the location using the overlay arrow and set the window point. Once we have passed beyond the end of the last window I want to reposition the buffer so that the new hit is visible in the middle of the first window -- all this in order to minimize buffer movement.

What I want to achieve is that it should be as easy as possible (and future safe) for applications to present a buffer in Follow mode-like sense, even if the buffer is present in a window which isn't selected.

 

> When windows are aligned, Follow mode does not set the window start or do
> anything else to disturb the redisplay.

In my suggested approach, when windows are aligned, after each call to
redisplay-window, window-end is cheap (since it was just computed and is
hence marked as up-to-date) and since the windows are already properly
aligned you'd find that window-start does not need to be updated, which
in turn would ensure that the next redisplay-window is also cheap.

> In this scenario it would definitively help if there were a "window-only
> redisplay" or, even better, a "silent redisplay" that would calculate where
> the window would end up, but not actually draw anything. (Here, I must
> admit that my knowledge of the display engine is limited.)

My intention would be for redisplay-window to only update the matrices
(i.e. the internal representation of the rendered window) and let the
subsequent full redisplay deal with updating the display.  My
knowledge of the display engine is also limited, but I think such
a redisplay-window function should not be too hard to write.

Sounds like a very good idea!

Another thing -- you mentioned earlier that the region highlight is nowadays done in elisp, and that it might be possible for Follow mode to make it span multiple windows. Where can I find out more about this?

    -- Anders