Re: Yet another redisplay question

[Eli Zaretskii]

> Date: Tue, 06 Aug 2013 20:04:23 +0400
> From: Dmitry Antipov <address@hidden>
> CC: address@hidden
> 
> AFAICS redisplay engine does a lot of iterator movements backward to BEGV
> or forward to ZV.

We don't currently have a way of moving the iterator backward, only
forward.  When we need to go back, we just scan through the text, and
then re-seat the iterator at the new place and re-initialize it.

> From the redisplay's point of view, how much of buffer text beyond
> its visible boundaries (window-start) and (window-end) we should
> process to be sure that the visible part is displayed correctly?

It depends on what you mean by "redisplay".  When the display engine
has already decided where window-start should be, and is just
redrawing the window, the answer is "none": it never processes any
text outside of the visible portion of text.

But in order to decide where the window should start, the display
engine many times needs to look beyond the window edges.  As a simple
example, consider a case where point was moved to some arbitrary
position outside of the window (e.g., with goto-char) -- how can the
display engine know what should be the new window-start that will
bring point back into view, when each line could be of different
height?  To do that, the display engine processes some text outside of
the window until it finds buffer position that satisfies user
requirements for this case (the various scroll-* variables).

> In particular, when we're looking for the beginning of the previous line,
> or the end of the current line, why not limit the search within the
> visible part of text?

Depends on why are we looking for the beginning of the line.
Sometimes we can just start from the window-start position, in that
case we don't need to search at all (because the window's start is
part of the window object data).  But if you want to know which
character is the first character of the line (e.g., for determining
the base direction of the paragraph for bidi display purposes), then
you must go to the beginning of the line.

Another example when you cannot stop at the beginning of the window is
when you need to start from a known horizontal position, e.g. as part
of vertical-motion: the only place in a line where the horizontal
position is known in advance is the line's beginning.

There are other cases.  Search the sources for "start_display" --
almost all of its calls are needed to find buffer positions which
satisfy some requirements, like given pixel coordinates.  Many of
these places examine text outside of the window, because at that point
it is not yet known where the window will start and end.

So to summarize, there are some cases where you cannot optimize these
searches.  Of course, looking for clever algorithms or caches that
would optimize more cases than we have now is always welcome.