Re: Unfreezing the display during auto-repeated scrolling. [ Was: Aborting display. Is this possible? ]

[Eli Zaretskii]

> Date: Sun, 26 Oct 2014 12:43:33 +0000
> From: Alan Mackenzie <address@hidden>
> Cc: address@hidden, address@hidden
> 
> Here's what I've done:  Conceptually, ITs (i.e. "struct it"s, the
> iterators in xdisp.c) are used for two different purposes:
> (i) display;
> (ii) calculation of displayed character sizes, positions etc.
> I've distinguished these two cases by adding an extra boolean flag to IT,
> called `not_for_display'.  The functions `init_iterator' and
> `start_display' have got this as an extra boolean parameter.
> 
> Some of the ITs in window.c and xdisp.c are now designated
> `not_for_display'.
> 
> `handle_fontified_prop' now checks this flag in IT.  If both the flag and
> `use-default-face-for-fast-scrolling' are set, then fontification is not
> done.  The existing face (usually default) is simply left there.  The
> code doesn't also check for the event queue being non-empty - in
> practice, this didn't work very well.
> 
> Here's the code.  Comments and criticism would be welcome.

I'm afraid this is a non-starter.  Even if this feature is accepted
(and I don't like it), it cannot be controlled on such a low level.
You cannot possibly know, on this low level, which code will use the
"not for display" functions, even if today they are only used in a
context where ignoring font-lock faces might be OK.  You already
marked as "not for display" line-pixel-height, which must be accurate
in the results it returns, since otherwise it will violate its
contract.  Likewise in resize_mini_window (which is definitely "for
display"), redisplay_internal (likewise), etc.  OTOH, displaying
strings (e.g., as part of mode-line display) will never bump into
font-lock faces, so setting this flag there is not useful.

So if we go this way, we are digging a hole for ourselves -- it is an
impossible maintenance burden to have functions that don't exactly do
what they say they do under some circumstances.

You should only make changes in window_scroll_* functions, and do that
only under control of the use-default-face-for-fast-scrolling
variable, so that the Lisp application that binds this variable to a
non-nil value is the sole source of this behavior, and holds all the
responsibility for binding it where it wants.  No code should
disregard font-lock faces, except when this variable is non-nil.

And I still don't understand why writing a simple "fast-scroll"
function in Lisp, which just moves point N lines forward or backward,
is not a better solution.  It's certainly easier and has exactly zero
impact on our infrastructure.

Thanks.