Re: Tick Reduction

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 19 Nov 2021 13:22:16 -0500
> 
> >> Clearly, we would benefit from a formal markup language (and one which
> >> includes some way to align text into columns).
> >
> > AFAIU, markup is generally separate from layout, so aligning text is
> > not part of what markup is supposed to solve.
> 
> Not sure what you mean: in order to know that the columns need to be
> aligned, the code that does the layout will need to be told about it by
> some markup.

What I mean is that markup generally tells nothing about layout, and
alignment is part of layout.

> > it examines text one character at a time and makes layout
> > decisions as part of that examination.  What you want would AFAIU
> > require the display engine perform layout of the entire window above
> > the line currently being laid out, before the layout of the current
> > line can be performed.
> 
> AFAIK, the way the display engine works currently, when we process
> a given char at POS, we have already processed all the chars between
> `window-start` and POS

That is only true when the window is redisplayed in its entirety, top
to bottom.  This happens relatively rarely, because the display engine
tries very hard not to redisplay much more than absolutely necessary.
These redisplay optimizations are generally structure as follows:

 . find the beginning and the end of the part of the buffer that needs
   to be redisplayed
 . redisplay that part starting at its beginning and going to its end

This could result in redisplaying just one line, for example, or all
lines between N and M.  Which means that redisplay of a window can
start at some arbitrary point in the middle of the window, without
knowing anything about the preceding lines, except that they weren't
changed on the glass.

Basically any display engine algorithm is required to support a
redisplay that begins at an arbitrary point in the buffer, and not
rely on the glyph matrices to be up-to-date.

> so I think we could handle the case of "align
> with some previous line" (with some non-trivial caveats since it means
> that future changes in that previous line would need to cause POS to be
> re-processed, which may require disabling some optimizations).

What you want would require every redisplay to always redraw the
entire window.  IOW, disable _all_ redisplay optimizations.

> Of course, to really auto-align columns, we can't just "align
> with some previous line", but we'd also need to align with some
> subsequent line, which means it can't be done in a single pass.

Ouch!