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

[Eli Zaretskii]

> Date: Sun, 26 Oct 2014 20:03:13 +0000
> Cc: address@hidden, address@hidden
> From: Alan Mackenzie <address@hidden>
> 
> > 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.
> 
> The contract of xdisp.c says explicitly that the only visible display
> function is redisplay, and this has no IT parameters.  So any IT with
> not_for_display set should be "safe" if it is defined outside of xdisp.c

No, that's wrong, because subroutines of redisplay_internal call the
"not-for-display" functions in many places, and they certainly do NOT
expect that those function behave differently, in terms of pixel
metrics and coordinates, from the "real" display.  E.g., if a series
of move_it_* calls with a certain goal winds up at some pixel
coordinates within the current window, the code expects to find itself
at the same place when it actually displays the text.  If this
condition is violated (because move_it_* functions ignore font-lock
faces), then all kinds of subtle breakage will ensue.

> > 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.
> 
> Sorry, I'd left unnecessary not_for_display's set.  I've cleared out
> xdisp.c, such that the only function which sets not_for_display is
> pos_visible_p.

That's also wrong: that function is a base for many APIs, specifically
the posn-at-* functions, that many features use and depend on.  You
cannot violate their accuracy.

> The other functions which set not_for_display are
> (i) window_scroll_pixel_based (window.c);
> (ii) Fvertical_motion (indent.c).

Fvertical_motion is called in many places.  Martin worked very hard to
make window and frame redisplay be accurate to a single pixel; you are
now going to ruin all that.

> > 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.
> 
> Yes.  But the current implementation doesn't work very well.  I'm trying
> to fix it, because it's irritating.  I think I've made good progress.  I
> can't see any other approach to fixing it at the moment.

I do, at least two of them, and I pointed them out.  In any case, if
there's no good solution for a problem, it certainly doesn't mean we
should compromise with a not-so-good one.

> > You should only make changes in window_scroll_* functions, ...
> 
> I honestly can't see how I could achieve what's wanted if I restrict
> myself to window.c.

Please tell what prevents you from doing that.

> > 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.
> 
> That's precisely how Fscroll_up and Fscroll_down work.

No, they don't.  If they did, you wouldn't need to disable
fontification, because moving point doesn't need it.

What Fscroll_down and Fscroll_up do is move the _window_start_, and
then figure out whether point is still visible after that.  When you
move point first, all this is not needed, especially if you don't care
that point will move slightly less or more than a screenful.